How it works
A random ID such as a UUID v4 lands in a random place in a database index every time you insert a row. On a big table that means more page splits, more cache misses and slower inserts. An ID that starts with the time always lands at the end, like an auto-increment number, but can still be made on any machine without asking the database.
UUID v7 is the standard one (RFC 9562). It has a 48-bit timestamp in milliseconds, then random bits, and fits an ordinary 16-byte uuid column. ULID is a similar 128-bit ID written in 26 characters that sort as text. A Snowflake ID is a 64-bit number: 41 bits of time, 10 bits for the machine and 12 bits for a counter, so it fits a bigint column. A KSUID is 27 characters with time to the second and 128 random bits.
Choose “A time I choose” to make IDs for a past or future moment, for example when importing old data. Tick “lowest possible ID” to get the smallest ID for that time. Use it as a boundary in a query, such as all rows created after midnight.
IDs made together in the same millisecond still sort in the order they were made, because the tool counts up instead of picking fresh random bits each time.
Good to know
Which to pick: UUID v7 if your database has a uuid type or you want a standard. Snowflake if you want the smallest key (8 bytes) and can give each machine a number. ULID if you want a short text key. KSUID if second precision is fine.
Recent versions of PostgreSQL have a built-in uuidv7() function. In MySQL, store UUIDs as BINARY(16) rather than text to keep the index small.
These IDs show when a row was created. If that matters for privacy, do not expose them in public URLs.
They are unique, not secret. Do not use them as passwords or access tokens.
Order across machines depends on their clocks. IDs from different servers sort by time only as well as the clocks agree.
Frequently asked questions
Why not just use an auto-increment number?
Auto-increment needs the database to hand out the number, which gets awkward with several writers, offline clients or sharded data. Time-ordered IDs can be made anywhere and still keep inserts in order.
How is UUID v7 different from UUID v4?
A v4 UUID is entirely random. A v7 UUID starts with the time, so rows sort by creation time and inserts stay fast. Both look the same and use the same column type.
How long until a Snowflake ID runs out?
The 41-bit time field lasts about 69 years from the epoch you pick. Each machine can make 4,096 IDs per millisecond.
Can I read the time back out of an ID?
Yes. Paste it into the box under the inputs. A Snowflake ID needs to know which epoch it was made with, so pick the same one above.
Is anything sent to a server?
No. The IDs are made in your browser, using its secure random number generator.