Tauschen Sie Ihr Postgres (noch) nicht gegen einen Rust‑Rewrite: Eine Risikokarte für CTOs

Hacker News liebt Rewrite‑Geschichten. Der Funke dieser Woche: eine Postgres‑kompatible Datenbank, in Rust neu geschrieben, die für sich beansprucht, 100 % der Postgres‑Regressionstests zu bestehen. Beeindruckend. Aber wenn Sie als CTO für RPO/RTO geradestehen, wissen Sie: 100 % einer Testsuite sind nicht 100 % Produktion. Ihre Aufgabe ist es nicht, der Speichersicherheit zuzujubeln – sondern Umsatz am Laufen und Daten langweilig zu halten. Dieser Beitrag liefert Ihnen eine konkrete, pointierte Risikokarte, bevor Sie überhaupt daran denken, Produktionsverkehr auf ein Greenfield‑Postgres‑in‑Rust zu lenken.

Was „100 % der Regressionstests“ tatsächlich bedeuten

Die Postgres‑Regressionssuite ist ein Schatz: Sie prüft SQL‑Syntax, Verhalten von Planner und Executor, Datentypen, Indizes, einige MVCC‑Semantiken und eine lange Liste an Kernfunktionen. Sie zu bestehen, ist die Eintrittskarte für Protokoll‑ und SQL‑Kompatibilität.

Aber sie ist kein Stellvertreter für Betriebstauglichkeit. Was diese Tests größtenteils nicht abdecken:

• Haltbarkeit bei echtem Stromausfall: fsync‑Verhalten über Dateisysteme hinweg (ext4, XFS, ZFS), Group‑Commit‑Timing, Erkennung zerrissener Seiten, WAL‑Segmentgrenzen.
• Replikations‑Edge‑Cases: Verhalten von Sync/Async‑Replikationsquoren, Timeline‑Wechsel, kaskadierte Replikas, verzögerte Standbys und Failover‑Fencing.
• Vacuum und Bloat unter Druck: Autovacuum‑Interaktionen bei hohen Schreibraten, HOT‑Updates, Genauigkeit der Visibility Map über Wochen unter Last.
• Upgrade‑Pfade: In‑Place‑Upgrades via pg_upgrade‑Semantik, Katalogmigrationen über Major‑Releases, logische Migrations‑Waggons.
• Observability‑Invarianten: Stabilität und Genauigkeit der pg_stat_*‑Views bei hoher Parallelität, auto_explain‑Hooks, Semantiken für das Zurücksetzen von Statistiken.

Das Bestehen der Suite sagt Ihnen, dass der Engine sich als Postgres ausgeben kann. Es sagt Ihnen nicht, was um 02:13 Uhr an einem Sonntag während einer rollierenden Netzpartition passiert, wenn Ihr Primary in einen fsync‑Stall läuft und Ihre Failover‑Logik nervös wird.

Kompatibilität geht weit über SQL hinaus

Wenn Sie für Postgres Bereitschaftsdienst gemacht haben, wissen Sie: Die „Datenbank“ ist ein Ökosystem, nicht nur ein Server‑Binary. Bevor Sie überhaupt einen Rust‑Rewrite im Labor testen, inventarisieren Sie die Features, die Sie wirklich nutzen:

• Extensions: pg_stat_statements, pgcrypto, pg_trgm, hstore, PostGIS, Timescale, HypoPG. Unterstützt der Rewrite die C‑ABI von Postgres für Erweiterungen? Falls nicht, welche Äquivalente gibt es und wie ausgereift sind sie?
• Logical decoding: Decoding‑Plugins (wal2json, pgoutput‑Varianten), Debezium‑Integration, Semantik von Replication Slots, Interaktionen mit Vacuum.
• Foreign Data Wrappers (FDWs): Nutzen Sie S3‑, Kafka‑ oder Cross‑DB‑FDWs? Wie geht der Rewrite damit um (falls überhaupt)?
• Protokoll‑ und Auth‑Besonderheiten: Verhalten auf Wire‑Level mit PgBouncer (Tx‑ vs. Session‑Pooling), SCRAM‑SHA‑256‑Auth, GSSAPI/Kerberos, SSL‑Renegotiation‑Policies.
• DDL‑ und Migrationstools: Flyway, Liquibase, Django, Rails, Prisma, TypeORM. Setzt irgendetwas bestimmtes Verhalten bei transaktionalem DDL, Advisory Locks oder search_path voraus?

Erstellen Sie eine einfache zweispaltige Tabelle für Ihren Stack: „genutztes Feature“ vs. „Status im Rust‑Rewrite“. Jede rote Zelle bei Extensions, Logical Decoding oder HA sollte Ihre Produktionsambitionen stoppen.

Operative Reife ist 80 % des Werts von Postgres

Vor zehn Jahren hieß Postgres in Produktion zu betreiben, dass man sich seine Sporen verdient. Heute macht das Ökosystem es fast langweilig – sofern Sie auf ausgetretenen Pfaden bleiben:

• HA/Failover: Patroni, Stolon, repmgr. Integriert sich der Rust‑Engine damit? Wenn nicht: Was orchestriert Leader‑Election, Fencing und Replica‑Bootstrap?
• Backup/PITR: Base‑Backups + WAL‑Archivierung mit pgBackRest oder WAL‑G. Sind Archivformate und Restore‑Mechanik kompatibel? Können Sie Point‑in‑Time‑Recovery auf einen beliebigen Timestamp nachweisen?
• Upgrades: Gibt es ein pg_upgrade‑Äquivalent oder machen Sie für jedes Major‑Release logische Migrationen?
• Observability: pg_stat_activity, pg_locks, pg_stat_replication, pg_stat_wal, pg_stat_io, auto_explain, Query‑Sampling, saubere log_line_prefix‑Hygiene. Können Ihre heutigen Dashboards und Alerts unverändert andocken?
• Vacuum, Bloat und Storage: Korrektheit der Visibility Map, Freeze‑Strategie, Erkennung und Minderung von Relation‑Bloat. Erhalten Sie Parität mit pg_stat_all_tables?

Wenn Ihre Antwort ist „Wir bauen unsere eigenen Operators und Backup‑Flows“, planen Sie entsprechend Budget ein. Sie tauschen ein Jahrzehnt community‑gehärtetes Muskelgedächtnis gegen ein neues, maßgeschneidertes Runbook.

Performance‑Aussagen brauchen Äpfel‑zu‑Äpfeln‑Maßstäbe

Rusts Speichersicherheit ist ein Gewinn. Sie sagt Ihnen, was nicht passieren wird (use‑after‑free), nicht was passieren wird (Latenz). Seien Sie skeptisch bei handverlesenen Grafiken. Definieren Sie Ihre Maßstäbe:

• Workload‑Form: OLTP (kleine Zeilen, heiße Indizes), leseintensive Dashboard‑Queries, analytische Scans? Nutzen Sie repräsentative Mischungen, nicht pgbench -S‑Fantasien.
• Latenz‑SLOs: p50 und p99 unter realistischer Parallelität. Verfolgen Sie das Schwanzverhalten während Checkpoints, Autovacuum‑Läufen und Failover‑Ereignissen.
• Feature‑Parität unter Last: JIT, parallele Abfragen, Bitmap‑Heap‑Scans, Druck auf work_mem, Sortier‑Spills, Gruppen‑Commit, Trade‑offs bei synchronous_commit.
• Hardware und FS: gleiche NVMe, gleiches Dateisystem, gleiche Mount‑Optionen (Barriers, noatime), gleicher Kernel. CPU pinnen, IRQs isolieren, Turbo deaktivieren, wenn Sie es ernst meinen.

Setzen Sie harte Gates. Zum Beispiel: „Rust‑Engine muss p99 innerhalb von 2× unserer getunten Postgres‑Baseline bei 2× unserer aktuellen QPS halten, über 7 Tage null Korrektheits‑Deltas zeigen und Failover‑RTO ≤ 90 Sekunden erreichen.“ Wenn sie das nicht mit Puffer schafft, kaufen Sie Risiko, nicht Performance.

Datenkorrektheit unter Stress: der einzige Benchmark, der zählt

Die meisten Desaster sehen nicht wie Crashes aus; sie sehen nach teilweisem Fortschritt aus. Genau dort verdienen Datenbank‑Engines ihr Geld. Prüfen Sie den Rewrite mit Jepsen‑Denke:

• Crash‑Schleifen an Schreib‑Hotspots: Prozess während WAL‑Flush per kill -9 beenden, während Checkpoints den Strom ziehen, unter Last wiederholen. Sehen Sie beim Neustart eine Erkennung zerrissener Seiten und konsistentes Replay?
• WAL‑Integrität: korrumpierte Segmente, teilweise Segment‑Archivierung, Idempotenz von Archiv/Restore, Timeline‑Verzweigungen. Können Sie zuverlässig auf N‑1 Transaktionen restaurieren?
• Replikations‑Wahrheit: synchrones Replica blockiert den Primary, asynchrones Replica hängt > 1 Stunde hinterher, Netzpartitionen. Sind Schreibbestätigungen im Einklang mit Ihrem synchronous_standby_names‑Vertrag?
• Checksums und Verifikation: Page Checksums an, Hintergrund‑Scrubbing, pg_checksums‑Äquivalente, proaktive Erkennungspfade in Logs und Metriken.

Schnell auf Happy Paths ist leicht. Richtig zu sein ist schwer, wenn der Kernel über Haltbarkeit lügt, Ihr SAN launisch ist und jemand über eine PDU stolpert.

Ein pragmatischer Einführungsweg, wenn Sie trotzdem einsteigen wollen

Wenn Sie fest entschlossen sind, ein Rust‑Postgres zu testen, beginnen Sie nicht mit dem Primary. Fahren Sie ein strukturiertes Programm:

1. Nach Blast Radius segmentieren: Wählen Sie eine risikoarme Workload mit kleinem Feature‑Footprint – überwiegend lesende interne Analytics oder einen neuen Microservice mit einfachem Schema. Vermeiden Sie PostGIS, Zeitreihenkompression oder schwere Trigger.
2. Kompatibilitätsmatrix aufbauen: Listen Sie jedes genutzte Feature (Extensions, Auth, CDC, FDWs) gegen den dokumentierten Support des Rewrites. Farbcode: grün/gelb/rot. Stoppen Sie bei Rot für CDC oder HA.
3. Echten Traffic replizieren: Dual‑write eines kleinen Prozentsatzes der Produktionsanfragen an beide Datenbanken (oder Replays echter Produktions‑Traces). Ergebnis‑Hashes speichern und vergleichen. Promotion nur bei null Korrektheits‑Deltas über 7–14 Tage.
4. CDC‑Paritätstest: Wenn Ihr Stack Debezium oder Downstream‑Konsumenten nutzt, binden Sie sie an den Rust‑Engine an. Verifizieren Sie, dass keine Events fehlen oder umgeordnet werden – insbesondere bei DDL‑Änderungen.
5. Backup/PITR‑Drills: Base‑Backup erstellen, WAL archivieren und ein zeitgesteuertes Restore auf T‑5 Minuten durchführen. Zeilenanzahlen, logische Checksums und anwendungsseitige Invarianten verifizieren.
6. HA‑Game Day: Primary während Peak‑Last zum Absturz bringen, Failover‑RTO/RPO gegen Ihre SLOs validieren und sicherstellen, dass Clients (via PgBouncer) ohne massenhafte Fehlermeldungen wieder verbinden.
7. Rollout‑Gates: Nach 2 aufeinanderfolgenden sauberen Wochen zu genau einem risikoarmen Produktionstenanten oder ‑umfeld promoten. Einen sofortigen Rollback‑Pfad via pg_dump oder logische Rückmigration auf Stock‑Postgres bereithalten.
8. Exit‑Plan dokumentiert: Entscheiden Sie jetzt, wie Sie aussteigen (Dump/Restore, logische Kopie). Validieren Sie das an einem nichttrivialen Datensatz, bevor Sie irgendetwas Kunden‑Facing shippen.

Timeboxen Sie das. Rechnen Sie mit 6–8 Wochen Dual‑Running und 2–3 Engineer‑Monaten, um mit Zuversicht zu einer Go/No‑Go‑Entscheidung zu kommen. Alles darunter ist Theater.

Wo ein Rust‑Rewrite heute glänzen könnte

• Edge‑ oder Embedded‑Deployments: Wenn der Engine einen kleineren Footprint oder besseres Cold‑Start‑Verhalten bietet, könnte er ideal für lokale Inference‑Caches oder Offline‑First‑Apps sein.
• Strenge Supply‑Chain‑ und Memory‑Safety‑Vorgaben: Regulierte Umgebungen, die Speichersicherheit und einen modernen Rust‑Code‑Base schätzen, akzeptieren ggf. operationale Trade‑offs für eine schmalere, sicherere Oberfläche.
• Greenfield‑Feature‑Slices: Ein interner Service mit einfachen Schemata und moderatem Traffic kann als Testfeld dienen, ohne Ihre Kernerlös‑Pfade zu verheddern.

Keines davon sollte Ihr Abrechnungssystem oder Ihr Kunden‑Identity‑Store sein.

Wann Sie vorerst Nein sagen sollten

• Extension‑schwere Deployments (PostGIS, Timescale, eigene C‑Extensions). Ohne ABI‑Parität verbringen Sie Quartale damit, ausgereifte, unterstützte Komponenten durch Lookalikes zu ersetzen.
• Multi‑Region‑HA mit straffen RPOs. Cross‑Region‑Replikation, Promotions‑Fencing und Split‑Brain‑Vermeidung sind Narben, die Sie nicht zweimal verdienen wollen.
• Hochvolumige CDC‑Pipelines, die Analytics oder Search speisen. Edge‑Cases im Logical Decoding sind der Ort, an dem Korrektheits‑Bugs lauern.
• Regulierte Workloads mit dokumentierten Kontrollen, FIPS‑validierter Kryptografie, deterministischen Backup/Restore‑Playbooks und Auditor‑freundlicher Observability.

Budgetieren Sie, was das tatsächlich kostet

Neue Engines ersetzen keine Budgetposten; sie schaffen neue. Grober Umfang für eine echte Evaluation (nicht ein Blog‑getriebenes Wochenende):

• Engineering: 2–3 Engineer‑Monate für Infra, Tests und Observability. Plus 1 SRE mit Vertrautheit mit Ihrem heutigen Postgres, um falsche Gleichsetzungen zu vermeiden.
• Tooling: Operatoren, Backup‑Skripte, Dashboards schreiben oder anpassen. Rechnen Sie mit 1–2 Wochen, um Parität zu Ihren heutigen Alerts zu erreichen.
• Chaos‑Zeit: mindestens zwei Game Days (Crash/Failover und Restore/PITR). Planen Sie je 6–8 Stunden mit anwesenden Stakeholdern ein.
• On‑Call‑Risiko: Im ersten Produktionsquartal kommen üblicherweise 2–3 zusätzliche Pages hinzu, bis die Runbooks stabil sind. Bepreisen Sie diesen Stress in Ihrer Entscheidung.

Wenn ein Vendor Ihnen das pitcht, bitten Sie ihn, die Tests mitzufinanzieren oder zu bemannen. Wenn nicht, ist das ein Signal.

Der Nearshore‑Hebel: Test‑Horsepower mieten, nicht Heldentaten

Diese Art von Evaluation ist perfekt für ein Nearshore‑Pod: repetitiv, diszipliniert, timeboxed und messbar. Mit 6–8 Stunden Overlap von Brazil in die US und einem 20–30%‑Kosten‑Vorteil gegenüber US‑Contractors können Sie ein kleines Squad aufsetzen, das:

• die Kompatibilitätsmatrix und Test‑Harnesses baut.
• HA‑, Backup‑ und Observability‑Stacks parallel hochzieht.
• Dual‑Writes fährt und Korrektheits‑Diffs über echte Traffic‑Replays vergleicht.
• Game Days automatisiert: Stromkappen, kill -9‑Schleifen und PITR‑Drills nach Plan.

Das Output, das Sie wollen, ist langweilig: grüne Dashboards, saubere Diffs und Runbooks, denen ein schläfriger On‑Caller um 2 Uhr morgens folgen kann.

Fazit

Rust ist nicht der Punkt. Datenkorrektheit und operativer Fleiß sind es. Ein Postgres‑Rewrite, der beides trifft, wird sich mit der Zeit seinen Platz verdienen. Bis dahin gilt: Behandeln Sie „100 % der Regressionstests“ als Einladung zur Evaluation – nicht als Erlaubnis zur Migration. Fahren Sie ein strukturiertes Programm, staffeln Sie Ihre Risiken und bestehen Sie auf langweiligen Ergebnissen, bevor Sie irgendetwas mit Kundennamen bewegen.

Kernpunkte

• Das Bestehen der Postgres‑Regressionssuite ist nötig, aber weit entfernt von Produktionsreife.
• Inventarisieren Sie Extensions, CDC, FDWs, Auth und Tooling; jede rote Zelle in Ihrer Matrix ist ein Stoppschild.
• Operative Reife (HA, PITR, Upgrades, Observability, Vacuum‑Hygiene) sind 80 % der eigentlichen Arbeit.
• Definieren Sie Performance‑Gates für p50/p99 unter realistischer Last und Chaos – nicht für Happy‑Path‑Mikrobenchmarks.
• Jepsen‑artige Crash‑, WAL‑ und Replikations‑Tests sind der Ort, an dem Korrektheits‑Bugs auftauchen – führen Sie sie durch.
• Adoptieren Sie über Piloten mit kleinem Blast Radius, Dual‑Writing und timeboxed Rollout‑Gates; halten Sie einen dokumentierten Exit‑Plan bereit.
• Sagen Sie „noch nicht“ bei extension‑schweren, Multi‑Region‑, CDC‑zentrierten oder regulierten Workloads.
• Rechnen Sie mit 2–3 Engineer‑Monaten für eine ernsthafte Evaluation; ziehen Sie ein Nearshore‑Pod in Betracht, um Kosten und Zeit zu bändigen.