# Adopted UUID v7 time‑ordered identifiers (PostgreSQL 18) as entity keys to reduce B‑tree index fragmentation and speed up queries. 2025 **Situation.** Every entity needs a unique id, and the reflex choice is a random UUID. The trouble is that random ids land all over a B‑tree index. Inserts scatter, the index fragments, and as tables grow both writes and range scans pay for it. On a platform meant to keep growing, that's a slow leak you'd rather not build in. **Task.** Keep the global uniqueness of a UUID but drop the fragmentation that comes with the randomness. **Action.** The standard became UUID v7, which is time‑ordered — the leading bits are a timestamp, so new rows sort into the index instead of peppering it. PostgreSQL 18 has this natively as uuidv7(), wrapped in a small uuid_generate_v7() function so the same call behaves cleanly on Azure's Flexible Server, then made the default for entity primary keys across the schema. Nothing exotic about it; it's the kind of decision that's cheap if you make it early and a pain to retrofit later. **Result.** Ids stayed globally unique, the index stopped fragmenting the way random UUIDs cause, and time‑ordered inserts and range queries got quicker — evenly, across every table, without anyone having to think about it again. As a bonus, every entity ends up with a key you can sort by time for free. --- - Role: Database Engineer - Categories: [Backend Engineering](https://data.engineer.company/categories/backend/), [Databases](https://data.engineer.company/categories/databases/), [PostgreSQL](https://data.engineer.company/categories/postgresql/), [Data Engineering](https://data.engineer.company/categories/data-engineering/), [Performance Tuning](https://data.engineer.company/categories/performance/) - Services: [Database Design & Modeling](https://data.engineer.company/services/database-design/), [Database Performance Tuning](https://data.engineer.company/services/database-performance/)