UUID v7

Original Article ↗ Hacker News Discussion ↗

PostgreSQL’s proposed support for UUID version 7 is prompting broader debate about how application and database IDs should be generated and used. Commenters weigh the benefits of time-ordered, index-friendly UUIDv7 keys—better insertion locality, sortable IDs, and easier distributed generation—against concerns over draft-spec stability, privacy leaks from embedded timestamps, and the complexity of overloading identifiers with extra semantics. Many argue that UUIDs (often v4 or v7) are preferable to auto-increment integers in distributed or public APIs, while others favor simple integer keys internally with separate external or timestamp fields for flexibility and security.

Status of UUID v7 in PostgreSQL

  • Patch exists and is small/isolated; main blocker is process/bandwidth and the spec still being a draft.
  • Some argue chances of spec changes are now very low; others say draft vs final is a hard line and there’s no urgency because extensions and app-side generation already work.
  • There is at least one well‑maintained extension (pg_uuidv7) that’s “within spec” already.

What “UUID v7 support” Means

  • PostgreSQL already stores any 128‑bit UUID and can use it in the uuid type.
  • The patch just adds built‑in functions to generate v7 inside the DB (convenience + some performance), versus generating in application code or via an extension.
  • v7 values remain fully compatible with existing uuid columns.

Reasons to Use UUID v7

  • Time‑ordered: v7 embeds a timestamp, making IDs roughly sortable by creation time.
  • Better index locality vs v4: sequential-ish values reduce b‑tree fragmentation and index/WAL bloating compared to random v4.
  • Useful for debugging and operationally understanding creation order, sometimes for partitioning and cursor‑like pagination.

Concerns and Downsides

  • Embedded timestamps can leak information (user signup times, medical event times, contract start/end hints), enabling profiling or competitive scraping.
  • Mixing identity and time in one field reduces flexibility; separate created_at columns are more controllable and can be hidden/exposed selectively.
  • General caution against adding extra semantics to IDs; future conflicts between “identity” and those semantics can be messy.

UUIDs vs Integers and Other ID Schemes

  • Strong debate:
    • Pro‑UUID: client‑side generation, easier offline/import workflows, no central sequence coordination, resistant to enumeration of internal scale, safer joins, easier global uniqueness.
    • Pro‑integer: better performance, simpler indexes/joins, well‑understood scaling with sequences/range allocation and sharding.
  • Some advocate hybrid schemas (internal bigint PK + external UUIDv4, possibly UUIDv7 internally), others are happy with UUIDv4 or v7 as PKs everywhere.
  • Alternatives mentioned: NanoID, Snowflake‑style IDs, other PG extensions (e.g., pg_idkit) for different ID formats.