Ich habe diesen Fehler genau einmal gemacht. Etwa drei Jahre in meiner AWS-Karriere übernahm ich eine Lambda-basierte API mit DynamoDB im Backend und sollte sie auf Aurora PostgreSQL migrieren – das Datenmodell war relational geworden und das Team wollte ordentliche Fremdschlüssel-Constraints.
Die Migration verlief in der UAT problemlos. Dienstagabend brachten wir sie in die Produktion. Bis Donnerstagmorgen war die Lambda-Konkurrrenz erschöpft, Aurora warf Verbindungs-Pool-Fehler, und ich saß mit dem CTO im Krisenraum und versuchte zu erklären, warum eine Datenbankmigration – kein Code-Change – einen kompletten API-Ausfall bei 80.000 RPS verursacht hatte.
Ich hatte nie getestet, wie sich das Verbindungsverhalten bei Produktionslast verhalten würde. Ich hatte angenommen, es würde schon funktionieren.
Es funktionierte nicht.
Man kann sich nicht durch Datenbankauswahl in großem Maßstab durchmogeln.
Die Methodik
Ich führte einen strukturierten Simulationsvergleich mit Pinpoles Pre-Deployment-Canvas durch. Zwei separate Canvases – eines für DynamoDB, eines für RDS/Aurora – mit einem dritten für Aurora Serverless v2 als Mittelweg-Vergleich.
Canvas-Topologie (beide Konfigurationen):
Route 53 → CloudFront → API Gateway → Lambda → [DynamoDB | RDS + Proxy] WAF (vor CloudFront) · SQS (entkoppelte Schreibpfade) · ElastiCache (RDS-Szenario)
Hinweis zu RDS Proxy: Wenn man Lambda in größerem Maßstab ohne RDS Proxy für das Verbindungsmanagement gegen RDS betreibt, wird man unter Last die Datenbankverbindungen erschöpfen. Das war im Wesentlichen der Architekturfehler, der zu meinem Dienstagnacht-Desaster führte. RDS Proxy ist in den RDS/Aurora-Konfigurationen unten immer vorhanden.
Alle Konfigurationen mit produktionsrealistischen Spezifikationen: Lambda mit 1.769 MB (entspricht 1 vCPU), 30-Sekunden-Timeout; API Gateway mit 10.000 RPS Burst-Limit; DynamoDB sowohl im On-Demand- als auch im Provisioned-Modus; RDS PostgreSQL auf db.r6g-Instanzen; Aurora Serverless v2 mit ACU-Limits entsprechend jeder Stufe.
Ich testete vier Verkehrsmodelle auf jedem RPS-Niveau: Konstant (gleichmäßige Basislast), Rampe (lineares Wachstum auf den Spitzenwert über 10 Minuten), Spitze (plötzlicher 10-facher Burst) und Welle (oszillierend zwischen 30 % und 100 % des Spitzenwerts). Jeder Durchlauf wurde zur Ausführungsgeschichte für Vergleiche gespeichert.
Ergebnisse bei 10.000 RPS
Konfiguration p50 p99 Monatliche Kosten DynamoDB On-Demand 2 ms 7 ms ~8.400 $ DynamoDB Provisioned (9.000 RCU / 1.000 WCU) 2 ms 7 ms ~1.150 $ RDS PostgreSQL db.r6g.2xlarge + Proxy 3 ms 11 ms ~870 $ Aurora MySQL db.r6g.2xlarge + Proxy 4 ms 13 ms ~980 $ Aurora Serverless v2 (durchschnittlich 4 ACU) 4 ms 15 ms ~720 $
Die größte Überraschung bei 10.000 RPS: DynamoDB On-Demand ist bei anhaltendem, vorhersehbarem Traffic fast 10-mal teurer als eine gut konfigurierte RDS-Instanz. Der Ruf von DynamoDB als „serverlose Datenbank“ verleitet Entwickler zu der Annahme, es sei bei moderaten Skalen günstig. Bei einem Produkt mit konsistenten tageszeitlichen Lastmustern ist Provisioned Capacity selten die falsche Wahl, und On-Demand selten die richtige.
Beim Spitzenmodell (10.000 → 100.000 RPS) bewältigte DynamoDB On-Demand den Anstieg ohne Konfigurationsänderungen. RDS PostgreSQL mit einer festen Instanz zeigte Verbindungs-Pool-Druck – p99 stieg für etwa 90 Sekunden auf 38 ms.
Ergebnisse bei 100.000 RPS
Konfiguration p50 p99 Monatliche Kosten DynamoDB Provisioned (autoskalierend) 2 ms 9 ms ~4.200 $ RDS PostgreSQL db.r6g.8xlarge + Proxy 3 ms 14 ms ~3.100 $ Aurora MySQL db.r6g.8xlarge + Proxy 4 ms 16 ms ~3.400 $ Aurora Serverless v2 (durchschnittlich 18 ACU) 4 ms 19 ms ~2.900 $
Bei 100.000 RPS wird DynamoDB On-Demand strukturell teuer. Das pro-Anfrage-Preismodell, das bei 10.000 RPS harmlos wirkt, skaliert linear. Provisioned DynamoDB mit Autoskalierung verändert das Bild deutlich. Die RDS-Kosten bleiben wettbewerbsfähig – der Overhead der festen Instanz wird nun effizienter amortisiert.
Das Spitzenmodell auf dieser Stufe lieferte die meisten diagnostischen Informationen. Die DynamoDB-Autoskalierung benötigte 3–7 Minuten für die vollständige Reaktion – währenddessen flaggte Pinpole erhöhte p99-Werte und empfahl aggressivere Scale-Out-Einstellungen. Dieses Verhalten muss man vor dem Deployment kennen.
KI-Zusammenfassung
Compare the performance and cost of DynamoDB and RDS at 10K, 100K, and 1M RPS. Learn how to make informed database selection decisions based on access pattern complexity, traffic predictability, and scale trajectory.
