🍐 Artikel 8: Vom Docker-Container zog unsere Datenbank auf eine stabilere AWS-Lösung um – Warum PEAR jetzt auf RDS läuft (und was das verändert)

🧭 Ausgangslage: Was vorher war

So Freunde, ich entschuldige mich hier bereits im Vorhinein, bei all Jenen, denen das hier gleich zu tehnisch wird, denn jetzt wird wirklich techy.
Bis letztes Wochenende lief PEARs Datenbank als klassische MySQL-Instanz, erst auf einer einzelnen Google Cloud VM (projekt-pear-vm), später dann auf einem Docker-Container in AWS (S3/Fargate). Beides jeweils lokal erreichbar, manuell administriert, mit schema.sql gepflegt – alles überschaubar, aber limitiert in Skalierung, Sicherheit und Monitoring. Wobei sich die AWS-Lösung gefühlt besser skalieren ließ.

Das reichte, solange PEAR in der Entwicklungsphase war. Doch um uns auf den baldigen Live-Betrieb aufzustellen – bei dem mehrere Benutzer:innen zeitgleich auf die Datenbanken zugreifen, Updates gefahren, Intake-Prozesse und automatisierte Workflows parallel abgearbeitet werden müssen – bremste auch das Docker-AWS-Setup mehr, als es half.

🚀 Zielbild: Die neue RDS-Infrastruktur

• RDS Single-AZ Setup für Einstieg im Free Tier, später ausbaubar
• DNS, Mail, Container-Workloads auf AWS konsolidiert
• Backup & Snapshots automatisch über AWS verwaltet
• Secrets Management & IAM-Rollen für Zugriffssicherheit
• EventBridge für zeitgesteuerte Tasks (Reminder, Cleanup)
• Multi-AZ-Konfiguration & Read Replicas vorbereitet für Skalierung

🔄 Der Migrationsprozess im Detail

1. VM → Dump: Bestehende MySQL-Datenbank mit mysqldump gesichert
2. Schema-Fixes: Namensauftrennung, Pflichtfeld-Erweiterungen
3. Import in RDS: manuell per CLI eingespielt
4. Secrets & VPC-Konfiguration: Zugriff über private Subnetze, IAM-basiert
5. DNS-Switch + Rollback-Option: Route 53, 30-Minuten-Fallback, GCP läuft noch als Schatteninstanz

🛠️ Lessons Learned (realistisch)

• Terraform ist nichts für Eilige: Schon beim Subnetz-Setup scheiterten erste Versuche – zu wenig Planung, zu viele Konflikte mit bestehenden Ressourcen
• Manuelle Ressourcen vs. IaC: RDS wurde letztlich manuell provisioniert – weil Terraform zu viele Brücken abbrennen wollte
• Secrets Manager ist Gold wert: Endlich kein wildes .env-Sharing mehr
• IAM schlägt Passwort-Fetischismus: Rollenbasierter Zugriff ist mächtiger – wenn sauber konfiguriert

📊 Was das für die Praxis bedeutet

🧭 Zeitplan & Fazit

Die Migration war kein Spaziergang – aber sie war machbar. Trotz zahlreicher Stolpersteine (Terraform, VPCs, DNS-Konflikte) konnten wir das neue System in der vorgesehenen Zeit umziehen und live nehmen. Es lief kein Rollback, keine verlorenen Daten, kein Chaos.

Die Umstellung war technisch fordernd, gelegentlich frustrierend – aber ein unumgänglicher Meilenstein, um PEAR production-ready zu machen.

Wer digital helfen will, braucht Systeme, die helfen – nicht Systeme, die selbst Pflege brauchen.
Willkommen im neuen Kapitel von PEAR. 🍐

🔄 Als nächstes steht die Migration des Datenbankstandorts von AWS US East nach Frankfurt (eu-central-1) an, um PEAR vollständig DSGVO-konform zu betreiben und alle geltenden Datenschutzrichtlinien verlässlich umzusetzen.