UUIDv4 vs. UUIDv7 in PostgreSQL: Performance und Sicherheit im Vergleich

Der Schutz sensibler Daten beginnt oft unscheinbar: mit einer simplen URL wie /api/v1/patienten/42. Doch genau diese scheinbar harmlose Praxis öffnet Türen für Angriffe. Plötzliche wird aus einer gut gemeinten Patienten-ID ein Einfallstor für Insecure Direct Object Reference (IDOR)-Schwachstellen. Entwickler stehen vor der Frage: Wie schützt man Ressourcen, ohne die Datenbankleistung zu opfern?

Warum Standard-UUIDs nicht immer die Lösung sind

MedicoSync, eine Open-Source-Plattform für medizinische Aufzeichnungen auf Basis von FastAPI und PostgreSQL, stand genau vor diesem Dilemma. Die naheliegende Lösung: UUIDs. Sie verschleiern interne IDs wie /api/v1/patients/550e8400-e29b-41d4-a716-446655440000 und beugen automatisierten Scans vor. Doch hinter der scheinbaren Einfachheit verbirgt sich ein leistungsrelevantes Detail.

Der Flaschenhals: B-Baum-Splits bei UUIDv4

PostgreSQL organisiert Daten effizient in B-Bäumen, einer Indexstruktur, die schnelle Such- und Schreiboperationen ermöglicht. Doch was passiert, wenn neue Zeilen mit zufälligen UUIDv4-Werten eingefügt werden?

Stellen Sie sich den Festplattenspeicher als eine Reihe nummerierter Boxen vor, die bereits vollständig gefüllt sind:

┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│ Box 1     │ │ Box 2     │ │ Box 3     │ │ Box 4     │
│ [VOLL]    │ │ [VOLL]    │ │ [VOLL]    │ │ [VOLL]    │
└───────────┘ └───────────┘ └───────────┘ └───────────┘

Ein neuer, zufälliger UUIDv4-Wert könnte genau in die Mitte von Box 2 fallen. PostgreSQL ist gezwungen, die Box zu teilen – ein B-Baum-Split entsteht. Die Folge:

• Die ursprüngliche Box 2 wird aufgeteilt in Box 2A und Box 2B.
• Alle nachfolgenden Boxen müssen nach rechts verschoben werden.
• Schreiboperationen verlangsamen sich spürbar, besonders bei Tabellen mit über einer Million Einträgen.

UUIDv7: Die zeitbasierte Alternative

Die Lösung liegt in der Struktur von UUIDv7. Im Gegensatz zu UUIDv4 ist es nicht vollständig zufällig, sondern folgt einem zeitgeprägten Muster:

UUIDv7-Layout = [ 48-Bit UNIX-Zeitstempel ][ 80 zufällige Bits ]

Der entscheidende Vorteil: Neue UUIDs sind immer größer als ihre Vorgänger. PostgreSQL kann sie direkt am Ende des Index anfügen, ohne Splits oder Umstrukturierungen zu benötigen:

┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│ Box 1     │ │ Box 2     │ │ Box 3     │ │ Box 4     │ │ Box 5     │
│ [VOLL]    │ │ [VOLL]    │ │ [VOLL]    │ │ [VOLL]    │ │ [NEU]     │
└───────────┘ └───────────┘ └───────────┘ └───────────┘ └─────────┬─┘
                                                                     │
                                                          Anhang ohne Splits

Das Ergebnis: keine Fragmentierung, keine Performance-Einbußen – selbst bei Millionen von Schreiboperationen.

Speicherbedarf: Ein notwendiger Kompromiss

Die Wahl zwischen Sicherheit und Effizienz ist selten kostenlos. Während ein BIGINT nur 8 Byte Speicher verbraucht, benötigt ein UUID 16 Byte – doppelt so viel. Doch der Mehraufwand lohnt sich:

• UUID (v4/v7): 16 Byte (Index- und Speicherplatz)
• BIGINT: 8 Byte (Index- und Speicherplatz)

Der zusätzliche Speicherbedarf ist vertretbar, wenn er die Sicherheit von Patienten- oder Unternehmensdaten gewährleistet. Für Systeme mit extrem hohen Schreiblasten kann jedoch eine Dual-ID-Strategie sinnvoll sein.

Die Dual-ID-Strategie: Sicherheit meets Performance

Nicht jede Schreiboperation ist gleich kritisch. Bei hohen Abfragevolumen kann es sinnvoll sein, interne und externe IDs zu trennen:

1. Externe ID (UUID): Wird für öffentliche APIs und Frontend-Kommunikation genutzt.
2. Interne ID (BIGINT): Bleibt im Backend und dient als effiziente Join-Basis.

┌──────────────────────────────────────────────────────────────┐
│ EINGEHENDE API-ANFRAGE                                       │
│ GET /api/v1/patienten/[EXTERNE_UUID]                         │
└───────────────────────┬──────────────────────────────────────┘
                        │
                        ▼
┌──────────────────────────────────────────────────────────────┐
│ BACKEND-DIENSTSCHICHT                                        │
│ 1. Externe UUID in interne BIGINT umwandeln (schnell)       │
└───────────────────────┬──────────────────────────────────────┘
                        │
                        ▼
┌──────────────────────────────────────────────────────────────┐
│ POSTGRESQL-DATENBANK                                        │
│ Führt JOINs mit BIGINT aus (hohe Performance)               │
└──────────────────────────────────────────────────────────────┘

• Vorteile:
• Schnelle JOIN-Operationen dank BIGINT.
• Externe UUIDs schützen vor automatisierten Scans.
• Flexibilität bei der Skalierung.

• Nachteile:
• Erhöhter Implementierungsaufwand.
• Zusätzliche Logik für die ID-Konvertierung.

Wann welche UUID-Strategie wählen?

Die Entscheidung hängt vom Projektstatus und den Anforderungen ab:

1. Neuprojekte: UUIDv7 als Standard

Für frische Projekte ist UUIDv7 die optimale Wahl. Es kombiniert:

• Sicherheit durch nicht vorhersagbare IDs.
• Performance durch zeitbasierte Speicherung.
• Einfachheit ohne zusätzliche Abstraktionsschichten.

2. Bestehende Systeme: Inkrementelle Migration

Wer bereits UUIDv4 einsetzt, sollte nicht übereilt migrieren. Stattdessen können JWT-Payloads mit verschlüsselten Metadaten genutzt werden, um IDOR-Schwachstellen zu schließen – ohne Schemaänderungen. Eine ausführliche Anleitung hierzu folgt in einem separaten Artikel.

3. Hochskalierende Systeme: Dual-ID-Architektur

Bei extrem hohen Schreiblasten (z. B. Millionen Einträge/Tag) empfiehlt sich die Dual-ID-Strategie. Sie entlastet die Datenbank und hält gleichzeitig die API-Schnittstellen sicher.

Fazit: Die Wahl liegt in Ihrer Hand

UUIDs sind kein Allheilmittel, aber sie bieten einen ausgewogenen Kompromiss zwischen Sicherheit und Performance. Während UUIDv4 in kleinen bis mittelgroßen Anwendungen funktioniert, wird UUIDv7 mit seiner zeitbasierten Struktur zum Game-Changer für wachsende Systeme. Für maximale Effizienz lohnt sich zudem die Trennung von internen und externen IDs – besonders wenn die Abfrageperformance zum Flaschenhals wird.

Die Zukunft gehört Systemen, die Sicherheit und Geschwindigkeit vereinen. Die Technologie ist da. Es liegt an Ihnen, sie richtig einzusetzen – bevor ein Angreifer Ihre Datenbank scannt.