Why You Should Stop Using UUIDv4

UUIDv4 is completely random, which destroys database performance as your table grows. B-Trees love sequential data, and UUIDv4 inserts are scattered randomly across the index tree.

When your table hits millions of rows, the database constantly reshuffles the index through page splitting, causing heavy disk I/O and catastrophic write performance degradation.

The solution: Use UUIDv7 (RFC draft) or ULID instead. These are time-ordered unique IDs that maintain global uniqueness while preserving sequential insertion performance.

Performance impact: Medium tables (1M-10M rows) see 10-30x faster inserts. Large tables (100M+) see 100x+ faster inserts.

Implementation options:

• PostgreSQL: Use uuid-ossp extension for gen_random_uuid() or install uuid7 extension
• Node.js: Use ulid() from ulidx library
• Python: Use uuid7() from uuid6 package

Migration from UUIDv4 is straightforward: Add a new column with the new ID type, backfill with new values, drop the old column.

Key takeaway: Your database index is the heart of query performance. Feed it sequential data, not random chaos. UUIDv7 and ULIDs give you global uniqueness with sequential performance.