Q.Snowflake ID vs UUID: which should you use?

Key numbers

Download the data (CSV): all four layouts with insert time, file size and lookup time.

How each one is built

Snowflake comes from Twitter, which needed IDs "under 64bits" when it moved off MySQL in 2010 and published the design as twitter/snowflake (Ryan King and team). A generator stamps the current millisecond, its own machine number and a counter that resets every millisecond. Two generators can't collide unless they share a machine number. Discord uses the same format with a 2015 epoch and splits the 10 machine bits into a 5-bit worker and a 5-bit process.

UUIDv7 was standardized in RFC 9562 in May 2024 (Kyzer Davis, Brad Peabody and Paul Leach). It puts a 48-bit Unix millisecond timestamp first and fills the rest with random bits, so any process anywhere can make one. PostgreSQL 18 ships a built-in uuidv7() function. Our UUIDv7 vs UUIDv4 test shows why the time prefix matters so much for database inserts.

The benchmark

We generated 2 million IDs of each type and inserted them into SQLite 3 with Python, in 50,000-row transactions, then timed 100,000 random lookups. One run each on a Windows 11 desktop, so read the ratios, not the exact seconds.

Three things explain the gap:

• Snowflake rides the row ID. In SQLite an INTEGER PRIMARY KEY is the table's internal row ID, so there is no separate index at all. Postgres and MySQL get a similar win from a native bigint key.
• UUIDs need a second structure unless you avoid it. A BLOB or TEXT primary key in a normal SQLite table means the table plus a separate index, which doubled the file (111.7 MB). WITHOUT ROWID stores rows in the key's own B-tree: 55.5 MB and the fastest UUID inserts.
• Text is the worst of both. 36 characters per ID instead of 16 bytes: 197.9 MB. Store UUIDs as binary or a native uuid type.

Lookups barely differed (3.36 to 4.02 seconds per 100,000), because all four are B-tree searches of similar depth. The difference is size and write speed, and size is what decides how much of your index fits in memory.

Try it: decode a Snowflake

Paste a Snowflake ID (for example a Discord message ID or an X post ID) to see when it was made. Runs in your browser; for the full breakdown use our Snowflake ID decoder.

That last line is the most common Snowflake bug: JavaScript numbers are exact only up to 2^53 - 1 (9,007,199,254,740,991), so a 19-digit Snowflake parsed with JSON.parse loses its last digits. Discord returns every ID as a string for exactly this reason.

Common misconceptions

Related

• UUIDv7 vs UUIDv4: which should you use?
• UUIDv7 vs ULID
• UUID vs NanoID
• How to extract the timestamp from a UUIDv7
• Article: We tested the UUIDv7 libraries
• Tools: Snowflake ID decoder, UUIDv7 generator

FAQ

What is the difference between a Snowflake ID and a UUID?

A Snowflake ID is a 64-bit integer made of a millisecond timestamp (41 bits), a machine ID (10 bits) and a per-millisecond sequence (12 bits), a format Twitter published in 2010. A UUID is 128 bits; version 7 (RFC 9562, 2024) holds a 48-bit Unix millisecond timestamp and 74 random bits. Snowflakes need a unique machine ID for every generator; UUIDv7 needs no coordination.

Is a Snowflake ID faster than UUIDv7 in a database?

Usually yes, because it is half the size and fits a native 64-bit integer column. In our 2-million-row SQLite test a Snowflake primary key inserted in 1.37 seconds versus 2.18 to 2.64 seconds for UUIDv7, and the database was 36.2 MB versus 55.5 to 197.9 MB. Point lookups were close: 3.36 versus 3.59 to 4.02 seconds per 100,000.

Why do APIs send Snowflake IDs as strings?

JavaScript numbers are exact only up to 2^53 - 1, and a Snowflake can use up to 63 bits, so parsing one as a number silently changes its last digits. Discord's API returns every Snowflake as a string for this reason, and Twitter's API added id_str fields.

How long do Snowflake IDs last?

Twitter's 41-bit millisecond timestamp covers about 69.7 years from its custom epoch of November 4, 2010, so it runs out in July 2080. UUIDv7's 48-bit Unix millisecond timestamp lasts until about the year 10889.

Can two Snowflake generators produce the same ID?

Only if they share a machine ID or a clock goes backwards. Each generator must have a unique 10-bit machine ID (1,024 in total), and Twitter's design refuses to generate IDs when the clock moves back. UUIDv7 avoids both problems by using random bits instead of a machine ID.

Sources

All checked October 24, 2026.

Specs and docs

• Twitter (Ryan King and contributors), twitter-archive/snowflake, snowflake-2010 branch README (2010): 41-bit time, 10-bit machine ID, 12-bit sequence, the 64-bit requirement and the backwards-clock rule.
• Discord, API Reference: Snowflakes: 2015 epoch (1420070400000), 5-bit worker and 5-bit process fields, IDs returned as strings.
• K. Davis, B. Peabody and P. Leach, IETF, RFC 9562: Universally Unique IDentifiers (UUIDs) (May 2024), section 5.7 UUID Version 7.
• PostgreSQL, UUID functions: uuidv7() since PostgreSQL 18.
• SQLite, Rowid tables (INTEGER PRIMARY KEY as the rowid alias) and Clustered indexes and WITHOUT ROWID.
• MDN, Number.MAX_SAFE_INTEGER.

Our data

• data.csv: our benchmark, October 24, 2026. 2,000,000 IDs per layout inserted with executemany in 50,000-row transactions; tables t(id <type> PRIMARY KEY, n INTEGER), plus a WITHOUT ROWID variant for the 16-byte blob; then 100,000 random point lookups. Python 3.12 sqlite3, journal_mode=off, synchronous=off, one run each, Windows 11 desktop. Snowflakes from a single-worker generator (Twitter epoch, worker 1); UUIDv7 from our own RFC 9562 generator (48-bit ms timestamp, 74 random bits). The run-out dates (2^41 ms after the Twitter epoch, 2^48 ms after 1970) are our math.

Images

• Benchmark charts rendered by Tensorust with the Proof Engine. Bit-layout diagram drawn by Tensorust from the README and RFC 9562. README screenshot: github.com, captured October 24, 2026.