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

NanoID's win is length, not speed. Stored as text, it made the smallest table (133.5 MB vs 198 MB for UUID text). Stored as a native 16-byte uuid column, UUID is smaller still.

Key facts

Download the data (CSV): all six benchmark runs.

How each one is built

UUIDv4 is 128 bits: 122 random, plus 4 version bits and 2 variant bits, printed as xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. UUIDv7 swaps the first 48 bits for a millisecond Unix timestamp, so new IDs sort after old ones (v7 vs v4 explained).

NanoID has no layout at all. It draws 21 random bytes from the platform's secure generator, keeps 6 bits of each and maps them to a 64-symbol alphabet: V1StGXR8_Z5jdHi6B-myT. Because 64 divides 256 evenly, there is no modulo bias. Andrey Sitnik's library also ships customAlphabet() for other alphabets and lengths, which uses a mask and rejects out-of-range bytes to stay unbiased.

Collision calculator

Change the length or alphabet to see how many IDs it takes to reach a 1% chance of any two matching (birthday bound). Nothing leaves your browser.

At the default 21 characters and 1,000 IDs an hour, a 1% chance takes about 149 billion years, the same figure as the Nano ID collision calculator by GitHub user zelark that the library's README links to. Cut it to 10 characters and the 1% point arrives after about 152 million IDs; 8 characters, about 2.4 million.

Our benchmark

We inserted 2 million IDs of each kind into a SQLite table with the ID as a text primary key, in 50,000-row transactions, twice: once as a normal rowid table (the key gets a separate index) and once WITHOUT ROWID (the table is the index). Python 3.12.10's sqlite3, journaling off, on a Windows 11 desktop. UUIDv7 came from our own RFC 9562 generator; NanoID from the same algorithm as the library.

What it shows:

1. Order beats length. NanoID is 42% shorter than a UUID string yet took only about 20% less time than UUIDv4 and 6.7 times slower than UUIDv7. Random keys force the database to write into the middle of its B-tree; time-ordered keys append to the end. The same effect is bigger at scale, as our 5-million-row v4 vs v7 test showed.
2. Length still saves disk. As text, NanoID used about a third less space. If your IDs live as strings anyway (JSON APIs, document stores, URLs), that is real.
3. Binary beats both. Postgres stores a uuid in 16 bytes; a 21-character text value takes 22 (a 1-byte header plus the characters). Our UUIDv7 vs ULID page measured text vs bytes directly.

Which should you use?

• Database primary key: UUIDv7 in a native uuid column. Sortable, standard, and Postgres 18 generates it with uuidv7().
• Public short links, invite codes, file names: NanoID, or a custom alphabet without look-alike characters.
• Both: a UUIDv7 key inside, a NanoID public_id column outside. Common in apps that do not want sequential or time-revealing IDs in URLs (UUIDv7 leaks its creation time; here is how to read it).

Common misconceptions

Related

• UUIDv7 vs UUIDv4: which should you use?
• UUIDv7 vs ULID
• How to extract the timestamp from a UUIDv7
• Tool: UUIDv7 generator and decoder
• Article: We tested the UUIDv7 libraries

FAQ

What is the difference between UUID and NanoID?

A UUID is a 128-bit ID standardized in RFC 9562 and usually written as 36 hex characters with hyphens; version 4 has 122 random bits. NanoID is a string generator from the nanoid JavaScript library: by default 21 characters from a 64-symbol URL-safe alphabet (A-Z, a-z, 0-9, underscore and hyphen), which gives 126 random bits. NanoID has no version bits, no timestamp and no standard binary form.

Is NanoID more likely to collide than UUID?

No. A default 21-character NanoID has 126 random bits against UUIDv4's 122, so it is slightly less likely to collide. You would need about 1.3 quintillion NanoIDs (roughly 149 billion years at 1,000 IDs an hour) for a 1% chance of one collision.

Is NanoID good as a database primary key?

It works, but it is fully random, so inserts land all over the index. In our test on a 2-million-row SQLite table, NanoID keys took 17.4 seconds to insert against 2.6 seconds for time-ordered UUIDv7. If you want short public IDs, a common pattern is a UUIDv7 primary key plus a NanoID column for URLs.

Can I make NanoID shorter?

Yes, nanoid(10) gives 10 characters, but collision odds rise fast: 10 characters is 60 bits, and a 1% chance of a collision arrives after about 152 million IDs. Use the calculator on this page before shortening.

Is NanoID secure?

The default nanoid() uses the platform's cryptographically secure random generator, so IDs are unpredictable. The separate nanoid/non-secure export uses Math.random and should not be used where guessing an ID would expose data.

Sources

All checked October 24, 2026.

Specs and libraries

• IETF, RFC 9562: Universally Unique IDentifiers (UUIDs) (May 2024): UUIDv4 and UUIDv7 layouts.
• Andrey Sitnik and contributors, ai/nanoid on GitHub (MIT license, 27.1k stars): default alphabet and length, 126 vs 122 random bits, customAlphabet, the non-secure export, and the library's own generation benchmark.
• zelark, Nano ID collision probability calculator, linked from the nanoid README.
• PostCSS, package metadata on npm (8.5.31): depends on nanoid ^3.3.20.
• PostgreSQL, UUID functions (uuidv7() since PostgreSQL 18) and character types storage (1-byte header for short strings).

Data

• npm registry downloads API, last week (October 16 to 22, 2026): nanoid, uuid, @paralleldrive/cuid2, ulid, uuidv7.

Our data

• data.csv: our benchmark, October 24, 2026. 2,000,000 IDs per run, inserted with executemany in 50,000-row transactions into CREATE TABLE t(id TEXT PRIMARY KEY, n INTEGER) with and without WITHOUT ROWID; Python 3.12.10 sqlite3, journal_mode=off, synchronous=off; one run each, Windows 11 desktop. UUIDv4 from Python's uuid.uuid4(); UUIDv7 from our own RFC 9562 generator (48-bit ms timestamp, 74 random bits); NanoID as 21 secure random bytes masked to 6 bits over A-Za-z0-9_-. Collision figures use the birthday bound n = sqrt(2 x ln(1/0.99) x alphabet^length) (our math).

Images

• All three charts rendered by Tensorust with the Proof Engine from our benchmark and npm data.