Har indført tidsordnede UUID v7‑identifikatorer (PostgreSQL 18) som entitetsnøgler for at reducere fragmentering af B‑tree‑indeks og øge forespørgselshastigheden.

Situation. Hver entitet har brug for et unikt id, og reflekvalget er en tilfældig UUID. Problemet er, at tilfældige id’er lander over det hele i et B‑tree‑indeks. Inserts spreder sig, indekset fragmenterer, og efterhånden som tabeller vokser, betaler både skrivninger og range‑scans for det. På en platform, der er ment til at blive ved med at vokse, er det en langsom lækage, man helst ikke vil bygge ind.

Opgave. Bevare en UUID’s globale unikhed, men slippe af med den fragmentering, tilfældigheden fører med sig.

Handling. Standarden blev UUID v7, som er tidsordnet — de førende bits er et tidsstempel, så nye rækker sorterer ind i indekset i stedet for at drysse det til. PostgreSQL 18 har det nativt som uuidv7(), pakket ind i en lille uuid_generate_v7()-funktion, så det samme kald opfører sig rent på Azures Flexible Server, og gjort til default for entiteters primærnøgler på tværs af skemaet. Intet eksotisk ved det; det er den slags beslutning, der er billig, hvis man træffer den tidligt, og en plage at eftermontere senere.

Resultat. Id’er forblev globalt unikke, indekset holdt op med at fragmentere, som tilfældige UUID’er får det til, og tidsordnede inserts og range‑forespørgsler blev hurtigere — jævnt, på tværs af hver tabel, uden at nogen skulle tænke over det igen. Som en bonus ender hver entitet med en nøgle, man kan sortere efter tid gratis.