UUID v4 is random, which makes it terrible as a primary key — every insert lands in a different page of the index. UUID v7 and ULID put a timestamp in front, so they sort by creation time and insert sequentially. Both are here, and both are correctly ordered across a batch.
What you can control
- Time-ordered formats increase monotonically down the batch, so you can verify sort order at a glance.
- The embedded timestamp can be shown as its own column for v7, ULID and ObjectId.
- Hyphens, braces and casing are all optional, covering the variations different systems store.
- Nano ID length is adjustable from 8 to 40 characters for trading collision risk against URL length.
What this is not
These come from a seeded pseudo-random generator, so collision resistance is nothing like a real UUID library's. Use crypto.randomUUID() in production.
Questions
Should I use v4 or v7 for a database key?
v7, in almost every case. Its leading timestamp means new rows insert at the end of the B-tree instead of scattering across it, which keeps write performance and index locality intact.
Are these safe to use as real identifiers?
No. The generator is seeded and deterministic, so the same seed reproduces the same IDs. Use your platform's crypto random source in production.
What is a ULID?
A 26-character identifier in Crockford base32: 48 bits of timestamp then 80 bits of randomness. It sorts lexicographically by time and is case-insensitive and URL-safe.