🍐 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 technisch 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. Beides jeweils lokal erreichbar, manuell administriert und 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 und Container-Workloads auf AWS konsolidiert
• Backup und Snapshots automatisch über AWS verwaltet
• Secrets Management und IAM-Rollen für Zugriffssicherheit
• EventBridge für zeitgesteuerte Tasks wie Reminder oder Cleanup
• Multi-AZ-Konfiguration und Read Replicas vorbereitet für spätere Skalierung

🔄 Der Migrationsprozess im Detail

1. VM → Dump: Bestehende MySQL-Datenbank mit mysqldump gesichert
2. Schema-Fixes: Namensauftrennung und Pflichtfeld-Erweiterungen vorgenommen
3. Import in RDS: Datenbank manuell per CLI eingespielt
4. Secrets & VPC-Konfiguration: Zugriff über private Subnetze und IAM-basierte Rollen vorbereitet
5. DNS-Switch + Rollback-Option: Route 53 mit Rückfallebene, damit der Umzug kontrolliert bleibt

🛠️ 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 bei Terraform, VPCs und DNS-Konflikten 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.