Evaluate UUID primary keys vs current ID scheme

[martinarva]

Context

From DoltHub Discord feedback (2026-04-03): Tim Sehn flagged that our VARCHAR(64) human-readable IDs (e.g. rr_lore_01) risk collisions in production. Dolt team recommends UUIDs.

Current state

The runtime ID generator already uses UUID4:

def _new_id(prefix: str) -> str:
    return f"{prefix}_{uuid.uuid4().hex[:12]}"

12 hex chars = 48 bits = ~281 trillion values per prefix. Collision risk is negligible at current scale. Seed data uses human-readable IDs (rr_lore_01) intentionally — these are examples and debugging aids, not production data.

Decision: skip for now

Full UUID migration (CHAR(36)) would touch 55 columns, 33 foreign keys, ~150 seed data IDs, and all 19 MCP tools. Large effort, minimal benefit at this stage.

If needed later

• Minimal fix: extend _new_id() hex from 12 to 16 chars (64 bits) — one-line change
• Full migration: needed if multi-tenant or cross-instance sync becomes a requirement
• Optional enhancement: add a slug column for human-readable display names alongside UUID PKs

Reference

• Dolt UUID blog post: https://www.dolthub.com/blog/2023-10-27-uuid-keys/