Issue UUID v4 and ULID identifiers for tables, events and test fixtures
Surrogate keys keep warehouses and microservices from colliding when sources merge. UUID version 4 is the familiar random identifier in APIs and Postgres extensions. ULIDs add lexicographic time ordering so log tailing and key-value stores see roughly chronological inserts without a separate created_at column in every index. This page generates both formats in the browser for migrations, seed scripts and notebook demos — nothing is posted to a server when you click generate.
Identifier workflow
- Choose UUID v4 for partner APIs or ULID for time-ordered event keys.
- Generate one id or a batch for spreadsheet imports.
- Copy lowercase or uppercase UUIDs to match your destination database convention.
- Load into staging with the SQL IN formatter when you need a WHERE clause list.
Database and streaming considerations
Random UUIDs scatter B-tree pages compared with sequential integers — acceptable at moderate scale, worth monitoring on hot primary keys. ULIDs reduce fragmentation in some engines but still are not as compact as bigint surrogates. Store canonical string form in varchar or use native uuid types when the engine supports them. When you debug JWT subjects or device ids, cross-check formats in the JWT Decoder after you generate test values here.
Testing and data generation
Synthetic datasets need unique keys per row without accidental duplicates from copy-paste. Generate batches, paste into CSV templates and profile results in the Data Profiler before you load to warehouse sandboxes. For numeric bitmask tutorials alongside ids, the Number Base Converter stays in the same utilities cluster. Document which id type each service owns so retries do not mint second keys for the same business event.
Operational hygiene
Never treat generated ids as unguessable secrets. They are identifiers, not bearer tokens. Log ids in structured JSON so you can correlate traces. When backfilling history, prefer ULIDs or time-prefixed keys only if downstream consumers already sort lexicographically — changing key style mid-stream breaks assumptions in dashboards you forgot about.
Batch generation tips
When you request dozens of ids for load tests, store them in a columnar file instead of a single comma-separated line so copy errors do not truncate entropy. Rotate test datasets between runs so caches keyed by id do not mask performance regressions. For databases that index random UUIDs heavily, monitor insert fragmentation — that is a storage concern, not something this generator solves, but it explains why teams pick ULIDs for append-heavy tables.
UUID v7: the time-ordered default for new keys
If you are choosing a key format for a brand new table, UUID version 7 is now worth a hard look. Standardised in RFC 9562, it keeps the familiar 8-4-4-4-12 UUID shape that every database and partner already accepts, while embedding a millisecond timestamp in the leading bits so rows insert in roughly chronological order. That gives you much of ULID's index-friendliness without adopting a non-UUID format your tooling might not recognise. Reach for v4 when you specifically want unguessable non-sequential ids. Choose ULID for its compact text form and prefer v7 when append-friendly primary keys and standard interchange both matter.