uuid.uuid4 vs uuid.uuid1: Localhost Lab

Intro — what this post promises

Generate IDs with uuid.uuid4 (random) vs uuid.uuid1 (time + node). This lab reports ops/s on Linux localhost, plus version/node checks.

Related links:

• 01shoppercove.compath read text vs open localhost lab
• 02shoppercove.comintenum vs int localhost lab
• 03shoppercove.comdataclass asdict vs vars localhost lab
• 04shoppercove.comtracemalloc snapshot localhost lab
• 05shoppercove.comselectors vs select localhost lab
• 06shoppercove.comliteral eval vs json localhost lab
• 07shoppercove.comcmath vs math hypot localhost lab
• 08shoppercove.comsignal vs event wakeup localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. Differentiates from uuid4-vs-secrets (lab 41) — that post compared uuid4 to secrets tokens; this one is uuid4 vs uuid1.

Verdict up front (n=100000): uuid4 ~966847 ops/s; uuid1 ~217847; with str(): uuid4 ~598452 vs uuid1 ~193085.

Arms

Seven rounds, p50. Sample versions: v4=4, v1=1, uuid1 node present=True.

Lab topology

n=100000 · 7 rounds · p50
metric: ops/s = n / p50_s

Script: lab-evidence/138-uuid4-vs-uuid1/results/run_lab.py.

Lead table (p50 ops/s)

uuid4 led by about 4.4× on object generation.

Semantics (why not only speed)

• uuid4: random; no MAC/time leakage; preferred for public IDs.
• uuid1: embeds timestamp + node; sortable-ish by time; can leak host identity.

Sample uuid1: f0ae2ffa-bd3a-11f1-b102-822b383dbcd0. Sample uuid4: 5a0e02bf-cad4-45ee-bdc2-acda319eb37c.

Reading it for SRE work

• Request IDs / public tokens → uuid4 (and see lab 41 if comparing to secrets).
• Need rough time ordering without a DB sequence → uuid1 can help; know the privacy trade.
• Stringifying costs real throughput — cache str only if you emit often.
• Do not assume uniqueness measurements here — this lab is throughput + version checks only.

Stringify tax

str(uuid4) fell to ~598452 ops/s from ~966847 object-only. Same pattern for uuid1 (~193085). Prefer .hex when you want compact text without hyphens (~758980).

Privacy vs ordering

If logs must not reveal which physical host minted an ID, skip uuid1 — its node field was non-zero on this box (node=True). If you only need “roughly increasing” IDs for debugging, uuid1’s timestamp can help operators skim timelines, but a server-side monotonic ID is usually clearer. Measure your generator under load before blaming the database for insert latency.

Ops vs secrets (pointer)

Lab 41 compared uuid4 to secrets token helpers. This post’s peer is uuid1. If you need opaque URL-safe tokens rather than UUID layout, prefer the secrets lab’s guidance; if you need UUID-shaped IDs, uuid4 ~966847 ops/s is the faster stdlib UUID here versus uuid1’s ~217847.

Pitfalls

• Using uuid1 in multi-tenant SaaS where node/MAC leakage matters.
• Comparing to lab 41 secrets numbers without stating the peer.
• Expecting uuid1 to be “free” because it is not CSPRNG — it was slower here.
• Treating throughput as a uniqueness proof.

Reproduce

python3 lab-evidence/138-uuid4-vs-uuid1/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box. Generation only — not collision tests, not DB index locality studies.

Store the UUID form your APIs already emit — converting layouts in every handler wastes the generator win.

Takeaway

uuid4 ~966847 ops/s beat uuid1 ~217847 and avoids time/node leakage. Prefer uuid4 for general IDs; use uuid1 only when you explicitly want its time+node properties.