UUID and ULID: generate IDs for APIs and databases

Identifiers glue together rows, events and HTTP resources. UUIDs and ULIDs both aim for uniqueness without a central allocator in many designs—but they optimize for different ergonomics. Picking the wrong style early costs migration work when log volume or cross-region replication forces you to revisit keys.

Who this is for

• Engineers designing REST payloads, event envelopes or primary keys for services that span regions.
• Analysts prototyping pipelines that need stable surrogate keys before a warehouse assigns its own.

UUID v4: random and ubiquitous

Version 4 UUIDs lean on randomness for collision resistance in typical product scales. Libraries exist everywhere; humans rarely memorize them—that is fine. Document whether clients may mint IDs or whether only servers issue them so duplicate-submit retries stay predictable.

ULID: sort-friendly without claiming strict time order

ULIDs encode millisecond time in the leading characters so lexicographic sort roughly follows creation order—handy for logs, Kafka-style topics or directory listings when you accept approximate ordering and still want huge uniqueness space.

Treat identifier strings as opaque at boundaries: compare with consistent casing rules and reject malformed lengths early so bad inputs never reach storage layers. Databases and caches should share the same acceptance rules you document in OpenAPI or internal runbooks.

Practical generation path

For spreadsheets, fixtures or demo APIs, UUID & ULID generator creates single or bulk values without leaving the browser. Treat outputs as sample data until your backend policy governs production issuance.

When IDs ride inside JSON, keep payloads readable with JSON formatter during review and validate contracts with JSON validator or JSON Schema generator for longer-lived services.

Hiring context

Distributed-system hygiene still maps to roles surfaced in Skill trends. Anchor any market claims in Methodology.

UUID v4 versus ULID

Frequently asked questions

UUID versus ULID—which default?
Default to UUID v4 when you only need random uniqueness. Pick ULID when lexicographic sort approximates time order in logs or event topics.

Are browser-generated IDs production-safe?
Modern browsers provide strong randomness for v4, but production systems should centralize policy—prototypes differ from regulated workloads.

How do IDs show up in APIs?
Usually as string fields in JSON—keep format stable and validate at boundaries using formatter and validator habits above.

Scope and uniqueness promises

“Globally unique” only holds if every producer respects the same rules—clients minting IDs without coordination can collide with server issuance unless you partition scopes by tenant or namespace. Document whether duplicates are impossible, merely unlikely or acceptable under replay semantics. Event-sourced systems sometimes reuse deterministic IDs for idempotent retries; databases want surrogate keys that never recycle—say which world you live in.

Storage, replication and migration

Indexed columns filled with random UUIDs fragment differently than monotonic integers—still cheaper than late-night key remediation. When you replicate across regions agree on string casing and hyphen placement so equality checks stay portable. Migrating from integers to UUIDs needs backfill plans and foreign-key updates; migrating between UUID and ULID touches sort semantics in logs and directories.

APIs, JSON and hiring context

Keep identifiers as explicit string fields in JSON; avoid numeric types that lose precision for large integers in JavaScript runtimes. JSON formatter and JSON validator keep payloads readable during review. Skill trends helps when distributed-system literacy shows up in postings; anchor claims with Methodology.

Collisions, retries and observability

Random IDs collide rarely—yet observability should still flag duplicate primary key attempts so silent corruption never passes as success. Retries that replay POST bodies may resubmit the same client-generated ID; servers must recognize duplicates or clients must switch to idempotency keys defined outside raw UUID minting. Log lines should print identifiers verbatim without truncation when engineers paste them into support tickets.

ULID ordering without promising clocks

ULID sorts approximate creation order—it does not replace true clocks or vector timestamps for causal ordering. Never infer strict happened-before relationships from lexicographic order alone when correctness depends on concurrency semantics.

Public APIs and opaque identifiers

Clients should treat identifiers as opaque strings even when ULID prefixes hint at time—parsing them couples mobile apps to storage layout you may change. Version your API when identifier formats shift so old binaries keep working through overlapping deploys. JSON formatter keeps review readable while JSON validator encodes string versus integer decisions explicitly.

Analytics joins and surrogate keys

Warehouse models often map natural business keys to surrogate integers—when event streams already carry UUIDs decide whether you hash them to smaller keys or keep strings for debuggability. Consistency between operational stores and analytics matters more than micro-optimizing width on day one.

Bottom line

Pick UUID v4 for pure uniqueness; pick ULID when rough time ordering buys operational clarity. Generate carefully, document scope and treat IDs as part of the contract—not decoration.