Question 1

Wie migrieren Sie eine laufende Datenbank ohne Ausfall?

Accepted Answer

Indem die Änderung umkehrbar und schrittweise erfolgt statt als einmaliger Umschalter. Der Standardweg ist Expand-and-Contract: neue Spalte, Tabelle oder Datenbank neben der alten anlegen, eine Zeit lang doppelt schreiben, Bestandsdaten in Batches nachziehen, die keine Sperre erzeugen, nach Verifikation die Lesezugriffe umstellen und die alte Struktur in einem späteren Release entfernen. Echte Null-Ausfallzeit hängt von Ihrem Stack ab, deshalb nennen wir ein realistisch kurzes Cutover-Fenster, statt Null zu versprechen und es nachts um zwei anders zu erleben.

Question 2

Kann durch die Optimierung etwas kaputtgehen?

Accepted Answer

Index- und Query-Arbeit ist bei einzeln geprüften Änderungen meist risikoarm, aber es gibt reale Gefahren: Ein Index auf einer großen Tabelle kann Schreibzugriffe sperren, wenn er falsch erzeugt wird, und ein umgeschriebenes Statement kann bei NULL-Werten oder Duplikaten unbemerkt andere Ergebnisse liefern. Wir testen auf einer Kopie mit produktionsnaher Datenmenge, erzeugen Indizes concurrently, wo die Engine es unterstützt, und vergleichen Ergebnismengen vorher und nachher, statt Gleichheit anzunehmen.

Question 3

Benötigen Sie Zugriff auf unsere Produktionsdatenbank?

Accepted Answer

Für die Diagnose deutlich weniger, als viele annehmen: Ausführungspläne, Slow-Query-Logs, Schemadefinitionen und Tabellenstatistiken reichen häufig aus und erfordern kein Lesen personenbezogener Datensätze. Wo direkter Zugriff nötig ist, arbeiten wir über eine benannte Rolle mit reinem Lesezugriff, und für Arbeiten mit Personenbezug bevorzugen wir eine maskierte oder reduzierte Kopie. Schreibrechte in der Produktion werden für ein konkretes Migrationsfenster erteilt, nicht dauerhaft.

Question 4

Unsere Hosting-Rechnung steigt, der Traffic aber nicht. Woran liegt das?

Accepted Answer

Bei verwalteten PostgreSQL-Diensten werden Datentransfer und Speicher oft getrennt von der Rechenleistung abgerechnet. Eine Anwendung, die ganze Tabellen liest, obwohl sie drei Spalten braucht, oder dieselben Zeilen bei jedem Request erneut lädt, erzeugt weit mehr Transfer, als der Traffic vermuten lässt. Genau das haben wir auf unserer eigenen Plattform verfolgt und durch schmale Projektionen, gebündelte Inserts, aggregierendes SQL statt zeilenweiser Roundtrips und eine Cache-Schicht mit definierter Invalidierung reduziert.

Question 5

Seit dem Wechsel zu Serverless häufen sich Verbindungslimit-Fehler. Warum?

Accepted Answer

Serverless-Funktionen skalieren horizontal, und jede Instanz kann eigene Verbindungen halten; eine Datenbank, die einem einzelnen langlebigen Applikationsserver problemlos genügte, erschöpft ihr Verbindungslimit dann schnell. Die Lösung ist ein korrekt platzierter Connection Pooler, ein passend konfigurierter Client, kurze Transaktionen und die Verlagerung von Arbeit ohne Verbindungsbedarf aus dem Request-Pfad. Das ist ein Designproblem, kein Kapazitätsproblem — ein größerer Tarif löst es selten.

Question 6

Wie entscheiden Sie zwischen Normalisierung und Denormalisierung?

Accepted Answer

Nach dem, was die Daten garantieren müssen, und danach, wie sie gelesen werden. Normalisierung verhindert widersprüchliche Daten und ist der richtige Standard für alles Transaktionale; Denormalisierung ist eine bewusste Performance-Entscheidung, die mit Update-Komplexität und Abweichungsrisiko bezahlt wird. Wir denormalisieren, wo ein Join auf heißen Pfaden nachweislich teuer ist, halten abgeleitete Daten über die Datenbank oder genau einen Codepfad konsistent und dokumentieren die Begründung.

Question 7

Wie finden Sie fehlende Indizes?

Accepted Answer

Über die reale Last statt über Vermutungen: Slow-Query-Logs, Ausführungspläne mit Sequential Scans auf großen Tabellen und Index-Nutzungsstatistiken, die sowohl ungenutzte Indizes als auch stark beanspruchte Tabellen ohne passenden Index zeigen. Bei zusammengesetzten Indizes ist die Spaltenreihenfolge ebenso entscheidend wie die Spaltenauswahl, und partielle Indizes schlagen bei gefilterten Abfragen oft breite Indizes. Wir prüfen zusätzlich die Schreibseite, weil jeder Index Inserts und Updates verteuert.

Question 8

Was passiert mit unseren Daten, wenn die Zusammenarbeit endet?

Accepted Answer

Sie bleiben, wo sie immer waren: in Ihrer Datenbank unter Ihrem Konto. Produktionsdaten von Kunden hosten wir nicht auf eigener Infrastruktur, sofern Sie das nicht ausdrücklich wünschen, und wir behalten nach Projektende keine Kopien über das für die Übergabe Vereinbarte hinaus. Sie erhalten Schemadokumentation, Migrationshistorie, Indexbegründungen und die Recovery-Prozedur, und wir übergeben auf Wunsch an Ihr nächstes Team.

Question 9

Wie berücksichtigen Sie DSGVO und Datenresidenz?

Accepted Answer

Region, Aufbewahrungsfristen und Zugriffsberechtigungen werden vorab schriftlich festgelegt, und bei geforderter EU-Datenresidenz wählen wir Datenbank- und Backup-Regionen entsprechend, einschließlich Replikaten. Wir arbeiten auf Basis eines Auftragsverarbeitungsvertrags mit dokumentierten technischen und organisatorischen Maßnahmen und kopieren keine personenbezogenen Produktionsdaten in Entwicklungsumgebungen; dort kommen maskierte oder synthetische Datensätze zum Einsatz.

Question 10

Wie werden Backups und Point-in-Time-Recovery gehandhabt?

Accepted Answer

Zuerst klären wir den akzeptablen Datenverlust und die angestrebte Wiederherstellungszeit, denn diese beiden Werte bestimmen alles Weitere; anschließend konfigurieren wir Backups und Aufbewahrung entsprechend und weisen sie durch eine echte Wiederherstellung in einer separaten Umgebung nach. Wir dokumentieren außerdem, wer eine Wiederherstellung auslösen darf und wie lange sie bei Ihrem Datenvolumen wirklich dauert — diese Messung ist wertlos, wenn sie erstmals im Störfall erfolgt.

Question 11

Unterstützen Sie Mandantentrennung?

Accepted Answer

Ja, und wir behandeln sie als Schema-Thema statt als Frage der Programmierdisziplin. Jede mandantenbezogene Tabelle führt einen Tenant-Schlüssel, Zugriffe laufen über Abfragen, die ihn nicht auslassen können, und Row-Level Security erzwingt die Grenze in der Datenbank statt im Gedächtnis der Entwickler. Dieses Muster haben wir in eine mandantenfähige KI-Supportplattform für ikas-Shops eingebaut, inklusive Nutzungs- und Kostenerfassung je Mandant.

Wie können wir helfen?

Datenbank-Services
FAQ

Hilfreiche
Informationen

Erste Schritte

Zeitplan

Preisgestaltung

Support

Noch Fragen?

Datenbank-ServicesFAQ

HilfreicheInformationen