Införde tidsordnade UUID v7‑identifierare (PostgreSQL 18) som entitetsnycklar för att minska fragmenteringen i B‑trädindex och snabba upp databasfrågor.

Situation. Varje entitet behöver ett unikt id, och reflexvalet är ett slumpmässigt UUID. Problemet är att slumpmässiga id:n hamnar huller om buller i ett B‑trädindex. Insättningarna sprids ut, indexet fragmenteras, och när tabellerna växer får både skrivningar och intervallskanningar betala för det. På en plattform som är tänkt att fortsätta växa är det ett långsamt läckage som man helst inte bygger in.

Uppgift. Att behålla den globala unikheten hos ett UUID men bli av med fragmenteringen som slumpmässigheten för med sig.

Handling. Standarden blev UUID v7, som är tidsordnat — de inledande bitarna är en tidsstämpel, så nya rader sorteras in i indexet i stället för att strös ut över det. PostgreSQL 18 har detta inbyggt som uuidv7(), som lindades in i en liten uuid_generate_v7()-funktion så att samma anrop fungerar rent på Flexible Server i Azure, och som sedan gjordes till standardvärde för entiteternas primärnycklar i hela schemat. Det är inget exotiskt med det; det är den sortens beslut som är billigt om man fattar det tidigt och besvärligt att bygga in i efterhand.

Resultat. Id:na förblev globalt unika, indexet slutade fragmenteras på det sätt som slumpmässiga UUID:n orsakar, och tidsordnade insättningar och intervallfrågor blev snabbare — jämnt, i varje tabell, utan att någon behöver tänka på det igen. Som en bonus får varje entitet en nyckel som du kan sortera på tid, helt gratis.