Was ist Serverless PostgreSQL?

Serverless PostgreSQL (Postgres) ist ein vollständig verwaltetes Cloud-Datenbankmodell, das Compute und Storage voneinander entkoppelt. Dies ermöglicht es beiden Komponenten, unabhängig voneinander und automatisch je nach Bedarf zu skalieren. Anstatt Datenbankserver direkt zu verwalten, interagieren Anwendungen mit Systemen, die Compute-Ressourcen als Reaktion auf die Arbeitslast automatisch bereitstellen und bei Inaktivität herunterskalieren.

In traditionellen Postgres-Umgebungen müssen Teams dagegen die Infrastruktur im Voraus dimensionieren, den Kapazitätsbedarf schätzen und die Skalierung im Laufe der Zeit verwalten. Dies führt häufig zu Überbereitstellung (Overprovisioning), unnötigen Kosten für ungenutzte Ressourcen und Leistungsengpässen, wenn die Nachfrage die verfügbare Kapazität übersteigt.

Serverless Postgres reduziert diesen Aufwand erheblich durch:

• Wegfall von Serverbereitstellung und Infrastrukturverwaltung
• Keine Notwendigkeit für manuelle Kapazitätsplanung
• Abrechnung nur für die tatsächliche Nutzung statt für ungenutzte Compute-Ressourcen

Der Begriff „Serverless“ kann irreführend sein, da er nicht bedeutet, dass Anwendungen ohne Server oder Infrastruktur laufen. Die zugrunde liegenden Systeme existieren weiterhin, sind jedoch abstrahiert und werden vollständig vom Cloud-Anbieter verwaltet. Aufgaben wie Server-Setup, Skalierung und Wartung sind für Benutzer weitgehend unsichtbar und müssen nicht direkt konfiguriert oder gewartet werden.

Traditionelles vs. Serverless PostgreSQL

PostgreSQL-Architekturen haben sich im Laufe der Zeit weiterentwickelt – weg von Modellen mit bereitgestellter (provisionierter) Infrastruktur hin zu dynamischeren, Cloud-nativen Designs.

Traditionelle Postgres-Bereitstellungen führen kontinuierlich feste Compute-Ressourcen aus, unabhängig von der Arbeitslast. Die Skalierung erfordert manuelle Eingriffe oder vorkonfigurierte Schwellenwerte, wobei auch dann dauerhafte Kosten anfallen, wenn eine Datenbank inaktiv ist.

Serverless Postgres führt ein anderes Modell ein. Compute-Ressourcen werden nach Bedarf bereitgestellt, skalieren automatisch mit der Aktivität der Arbeitslast und werden bei Nichtgebrauch auf Null herunterskaliert. Die Abrechnung basiert auf dem tatsächlichen Verbrauch und nicht auf reservierter Kapazität.

Serverless Postgres kann auch zusammen mit Serverless-Compute-Plattformen wie Databricks SQL verwendet werden. Dies ermöglicht es, analytische Abfragen unabhängig auszuführen, während weiterhin auf dieselben zugrunde liegenden Daten in einer einheitlichen Lakehouse-Architektur zugegriffen wird.

Dieser Wandel wird durch architektonische Änderungen wie entkoppelte Speicherebenen und On-Demand-Compute-Orchestrierung ermöglicht, wodurch Ressourcen unabhängig voneinander skalieren und dynamisch auf die Aktivität der Arbeitslast reagieren können.

Die wichtigsten Unterschiede im Überblick:

Die nächste Evolution: Lakebase-Architektur

Mit der Weiterentwicklung von Datenbankarchitekturen entsteht ein drittes Modell, das auf Serverless Postgres aufbaut und gleichzeitig dessen Einschränkungen behebt. Dieser Ansatz wird manchmal als Lakebase-Architektur bezeichnet.

Serverless Postgres verbessert die Skalierbarkeit und reduziert den Betriebsaufwand, bleibt jedoch in der Regel von analytischen Systemen getrennt. Diese Trennung erfordert häufig Datenverschiebungen, Duplikationen oder Synchronisierungen zwischen operativen Datenbanken und Analyseplattformen.

Lakebase-Architekturen verändern die Art und Weise, wie wir über Datenspeicherung und -verarbeitung denken. Sie kombinieren die Leistungsfähigkeit transaktionaler Datenbanken mit der Flexibilität einer Lakehouse-Basis und schaffen so eine einzige Plattform, auf der sowohl operative als auch analytische Arbeitslasten gemeinsam ausgeführt werden können. Das bedeutet, dass anstelle separater Systeme für verschiedene Aufgaben alles auf einer gemeinsamen Datenplattform erledigt werden kann. Das Ergebnis sind weniger Datenredundanzen und ein wesentlich einfacherer Zugriff auf Daten sowie deren Nutzung. Durch die Zusammenführung aller Komponenten erleichtern Lakebase-Architekturen die Verwaltung und Analyse von Daten, was zu einer besseren Entscheidungsfindung und effizienteren Abläufen führen kann.

So funktioniert die Lakebase-Architektur

Lakebase-Architekturen bauen auf Serverless-Postgres-Mustern auf und bieten gleichzeitig eine engere Integration mit Cloud-Speichern und Datenplattformen.

Die wichtigsten Komponenten sind:

• Entkoppeltes Compute und Storage
  Compute ist zustandslos (stateless) und skaliert unabhängig, während der Speicher persistent und verteilt bleibt.
• Ephemeres Compute
  Compute-Ressourcen werden gestartet, um Abfragen zu verarbeiten, und bei Inaktivität wieder herunterskaliert. Dies ermöglicht Elastizität, ohne dass eine dauerhaft aktive Infrastruktur unterhalten werden muss.
• Protokollbasierte Speichersysteme
  Datenänderungen werden als kontinuierliches Protokoll (Log) erfasst, mit dem der Datenbankzustand rekonstruiert und Funktionen wie Branching, Wiederherstellung und zeitbasierter Zugriff unterstützt werden können.
• Objektspeicher als Grundlage
  Dauerhafte Daten werden im Cloud-Objektspeicher gespeichert, was Skalierbarkeit, Langlebigkeit und die Abstimmung auf Lakehouse-Architekturen ermöglicht.
• Control Plane und Orchestrierung
  Eine Steuerungsebene (Control Plane) verwaltet Skalierung, Routing und Lebenszyklus-Ereignisse und koordiniert Compute und Storage dynamisch.

Warum das wichtig ist

Durch die Kombination von transaktionalen und analytischen Funktionen auf einer gemeinsamen Basis können Lakebase-Architekturen:

• Datenredundanzen zwischen Systemen reduzieren oder ganz vermeiden
• Analysen operativer Daten nahezu in Echtzeit ermöglichen
• Die Datenarchitektur durch die Konsolidierung der Infrastruktur vereinfachen
• Neue Arbeitslasten unterstützen, einschließlich AI-Anwendungen, die sowohl transaktionalen als auch analytischen Zugriff erfordern

Dieser Wandel spiegelt den Übergang von der Optimierung einzelner Systeme hin zu deren Vereinheitlichung in einer einzigen Datenarchitektur wider.

So funktioniert die Serverless-Postgres-Architektur

Serverless Postgres basiert auf einer Cloud-nativen Architektur, die Compute und Storage in unabhängige Ebenen unterteilt. Dieses grundlegende Designprinzip verbessert die Effizienz und Flexibilität, da jede Komponente unabhängig voneinander skaliert werden kann.

Ein Hauptmerkmal dieser Architektur ist das Scale-to-Zero-Verhalten. Wenn keine Abfragen ausgeführt werden, stoppt das System automatisch die Compute-Ressourcen. Sobald eine neue Abfrage gesendet wird, wird Compute reaktiviert. Dies führt zu einer kurzen Verzögerung, der sogenannten Kaltstart-Latenz (Cold Start Latency), die je nach Anbieter und Konfiguration zwischen Millisekunden und mehreren Sekunden liegen kann.

Eine weitere wichtige Funktion ist das Datenbank-Branching, das häufig mithilfe von Copy-on-Write-Techniken implementiert wird. Branching ermöglicht es Teams, isolierte Datenbankumgebungen für Entwicklung, Tests oder Staging zu erstellen, ohne Daten zu duplizieren. In einem Branch vorgenommene Änderungen haben keine Auswirkungen auf die ursprüngliche Datenbank, was schnellere Iterationen und sichereres Experimentieren ermöglicht.

Wichtige Anbieter von Serverless Postgres

Serverless-Postgres-Angebote spiegeln verschiedene Phasen der Entwicklung von bereitgestellten Datenbanken hin zu vollständig Cloud-nativen Architekturen wider. Frühere Managed Services führten eine automatische Skalierung innerhalb bestehender Datenbankarchitekturen ein. Neuere Cloud-native Designs sind so konzipiert, dass sie AI-Agents, Echtzeitanwendungen und moderne operative Arbeitslasten unterstützen. Diese Systeme entkoppeln Compute und Storage vollständig und bieten Funktionen, die in früheren Modellen nur schwer zu realisieren waren, wie z. B. schnelle Skalierung, Branching und eine flexiblere Ressourcenverwaltung. Neon und Databricks Lakebase bauen auf dieser Grundlage auf und sind für die Anforderungen von zukunftsorientierten AI-Anwendungen und agentenbasierten Systemen konzipiert.

• Databricks Lakebase
  Eine operative Datenbank, die auf der Lakebase-Architektur basiert und Serverless Postgres durch die Integration transaktionaler Datenbanken in eine Lakehouse-Basis erweitert. Databricks Lakebase wurde für die Anforderungen von AI-Agents, Echtzeitanwendungen und modernen operativen Arbeitslasten entwickelt und ermöglicht es operativen und analytischen Arbeitslasten, eine gemeinsame Datenplattform zu nutzen. Zu den Anwendungsfällen gehören das Speichern des Status von AI-Agents, das Betreiben transaktionaler Anwendungen und die Bereitstellung analytischer Erkenntnisse direkt in Apps und Workflows. Das Ergebnis sind weniger Datenverschiebungen und ein konsistenterer Zugriff über verschiedene Anwendungsfälle hinweg.
• Amazon Aurora Serverless v2
  Ein Postgres-kompatibler Managed Service innerhalb von AWS, der eine feingranulare automatische Skalierung ohne erforderliche Datenbank-Neustarts bietet. Aurora Serverless v2 ist für Enterprise-Arbeitslasten konzipiert und eng in AWS-Dienste für Netzwerk, Sicherheit und Überwachung integriert. Obwohl dadurch der Betriebsaufwand reduziert wird, können das Skalierungsverhalten und die Ressourcenisolierung immer noch Einschränkungen der zugrunde liegenden Infrastruktur widerspiegeln.

Für Analyse- und Datenverarbeitungs-Workloads ist Serverless-Compute auch auf Plattformen wie Databricks SQL verfügbar. Obwohl es sich nicht um eine transaktionale (OLTP)-Datenbank handelt, bieten diese Systeme eine serverlose Abfrageausführung für Analysen und können parallel zu Postgres-basierten Systemen betrieben werden.

Open-Source-Wurzeln und Cloud-native Optionen

Postgres ist ein weit verbreitetes, relationales Open-Source-Datenbanksystem. Serverless-Postgres-Angebote bauen auf diesem Fundament auf und bieten volle Kompatibilität mit dem breiteren Postgres-Ökosystem, das Erweiterungen, Befehlszeilentools wie psql, gängige ORMs und mehr umfasst.

Die Implementierungen unterscheiden sich darin, wie viel des zugrunde liegenden Systems offen oder proprietär ist. Einige Anbieter wie Neon basieren auf Open-Source-Infrastruktur und legen mehr von ihrer Architektur für die Community offen. Andere, wie Amazon Aurora Serverless, sind proprietäre Managed Services, die einen Großteil der zugrunde liegenden Implementierung abstrahieren.

Unabhängig vom Ansatz zielen die meisten Serverless-Postgres-Lösungen darauf ab, die volle Postgres-Kompatibilität beizubehalten und gleichzeitig Cloud-native Funktionen wie automatische Skalierung, Datenbank-Branching und verwaltete Abläufe hinzuzufügen.

Diese Unterschiede können beeinflussen, wie viel Transparenz und Kontrolle Teams über Leistung und Kosten haben. Auf Open Source basierende Systeme bieten möglicherweise mehr Transparenz und Flexibilität, während proprietäre Managed Services oft Benutzerfreundlichkeit und betriebliche Einfachheit in den Vordergrund stellen.

Preismodelle und Performance-Kompromisse

Bei der Evaluierung von Serverless Postgres für Produktions-Workloads ist es wichtig zu verstehen, wie Preismodelle und Performance-Merkmale die Kosten, die Latenz und das gesamte Systemverhalten beeinflussen.

Nutzungsbasierte Preisgestaltung: Wofür Sie tatsächlich bezahlen

Die meisten Serverless-Postgres-Anbieter berechnen Gebühren nach drei Hauptdimensionen:

• Compute: Typischerweise gemessen an den während der Abfrageausführung genutzten Ressourcen, wie z. B. vCPU-Zeit oder ACU-Sekunden
• Storage: Abgerechnet nach der gespeicherten Datenmenge, in der Regel in GB pro Monat
• Datentransfer: Gebühren für Daten, die in die und aus der Datenbank übertragen werden, abhängig von Region und Netzwerkkonfiguration

Da Compute nach Bedarf bereitgestellt wird, skalieren die Kosten mit der Workload-Aktivität. Dadurch eignet sich die serverlose Preisgestaltung gut für Anwendungen mit variablem oder unvorhersehbarem Traffic.

Viele Anbieter bieten kostenlose Tarife an, die für Entwicklung, Tests und kleinere Workloads nützlich sind. Diese Tarife enthalten in der Regel Einschränkungen bei der Compute-Nutzung, dem Storage oder der aktiven Laufzeit, wodurch sie für Produktions-Workloads oder Anwendungen mit kontinuierlichem Traffic weniger geeignet sind.

Obwohl eine serverlose Preisgestaltung bei variablen Workloads effizient sein kann, ist sie nicht immer die kostengünstigste Option. Bei Workloads mit hohem Traffic, Always-on-Betrieb oder lang laufenden Abfragen können die Gesamtkosten die einer bereitgestellten Datenbankinstanz mit fester Kapazität übersteigen.

Kaltstarts, Skalierung und Produktionszuverlässigkeit

Einer der wichtigsten Performance-Aspekte bei Serverless Postgres ist die Kaltstart-Latenz. Wenn eine Datenbank auf Null herunterskaliert wurde, muss Compute erst reaktiviert werden, bevor Abfragen ausgeführt werden können. Dies führt zu einer Verzögerung, die je nach Anbieter und Konfiguration zwischen etwa 100 Millisekunden und mehreren Sekunden liegen kann.

Verschiedene Maßnahmen können die Auswirkungen von Kaltstarts verringern:

• Senden regelmäßiger „Keep-alive“-Pings, um eine vollständige Deaktivierung zu verhindern
• Konfigurieren einer minimalen Compute-Untergrenze, um Ressourcen teilweise aktiv zu halten
• Auswahl von Anbietern, die Kaltstarts durch architektonisches Design minimieren oder ganz vermeiden

Serverlose Systeme setzen zudem auf automatische Skalierung, um wechselnde Workloads zu bewältigen. Compute-Ressourcen können als Reaktion auf ein erhöhtes Abfragevolumen hochskaliert werden, und in einigen Fällen können Read Replicas unabhängig skaliert werden, um gleichzeitige Zugriffe zu unterstützen. Diese Elastizität ist besonders nützlich für Anwendungen mit unvorhersehbaren Traffic-Spitzen.

Für Produktions-Workloads sind Verfügbarkeit und Fehlertoleranz entscheidende Faktoren. Die meisten verwalteten Serverless-Postgres-Anbieter replizieren Daten über mehrere Verfügbarkeitszonen hinweg und bieten integrierte Backup- und Wiederherstellungsfunktionen. Die Service-Level-Garantien und das Wiederherstellungsverhalten variieren jedoch je nach Anbieter. Daher ist es wichtig, die SLA-Abdeckung vor dem produktiven Einsatz zu prüfen und zu verifizieren.

Funktionen wie das Kaltstart-Verhalten und die automatische Skalierung machen Serverless Postgres gut geeignet für Workloads mit variablem Traffic, können jedoch Kompromisse für latenzempfindliche oder Always-on-Anwendungen mit sich bringen.

Serverless Postgres: Anwendungsfälle und Einschränkungen

Serverless Postgres und die Lakebase-Architektur bedienen unterschiedliche Workload-Anforderungen. Zu verstehen, welches Modell zu Ihrem Anwendungsfall passt, kann helfen, unnötige Komplexität und Kosten zu vermeiden.

Die folgenden Richtlinien können Ihnen bei der Entscheidung helfen, ob Serverless Postgres oder eine Lakebase-Architektur die richtige Wahl für Ihren Workload ist.

Gut geeignet für Serverless Postgres

• Die meisten OLTP-Workloads

Besser geeignet für eine Lakebase-Architektur:

• Entwicklung und Bereitstellung von KI-Agenten
• Variable oder unregelmäßige Workloads
• Entwicklungs-, Test- und Staging-Umgebungen
• Startups, die auf Kosten und geringeren betrieblichen Aufwand optimieren
• Serverlose oder Edge-basierte Anwendungen
• CI/CD-Workflows mit schneller Erstellung von Umgebungen
• Mandantenfähige SaaS-Anwendungen (Branching und automatische Skalierung)

Für Workloads, die eine konsistentere Performance oder Always-on-Verfügbarkeit erfordern, adressiert die Lakebase-Architektur diese Anforderungen, indem sie die Koordinierung von Compute und Storage auf einer gemeinsamen Datenplattform neu überdenkt.

Erste Schritte mit Serverless Postgres

Der Einstieg in Serverless Postgres umfasst in der Regel einen unkomplizierten Einrichtungsprozess:

1. Wählen Sie einen Anbieter basierend auf Ihren Workload-Anforderungen, dem Skalierungsverhalten und den Präferenzen für das Ökosystem aus
2. Erstellen Sie eine Datenbankinstanz über die Konsole oder API des Anbieters
3. Konfigurieren Sie einen Verbindungsstring mit Anmeldedaten, Region und Zugriffseinstellungen
4. Stellen Sie eine Verbindung mit einem Standard-Postgres-Client, einem ORM oder dem psql-Befehlszeilentool her

Obwohl die Einrichtung relativ einfach ist, können frühe Entscheidungen tiefgreifende Auswirkungen auf die Gesamt-Performance und die Beständigkeit haben. Überlegungen zur ersten Bereitstellung sollten Folgendes umfassen:

• Festlegen einer minimalen Compute-Stufe, wenn die Kaltstart-Latenz ein Problem darstellt
• Konfigurieren eines Connection Poolers zur Verwaltung gleichzeitiger Verbindungen in Serverless- oder Edge-Umgebungen
• Aktivieren von Backups und Point-in-Time-Wiederherstellung zum Schutz vor Datenverlust
• Überprüfen der Skalierungs- und Timeout-Einstellungen, um sicherzustellen, dass sie mit den erwarteten Traffic-Mustern übereinstimmen

Serverless Postgres kann zusammen mit serverlosen Compute-Plattformen wie Databricks SQL für Analysen und Data Engineering verwendet werden. Diese Trennung ermöglicht es, analytische Abfragen unabhängig von der transaktionalen Verarbeitung auszuführen, während sie dennoch auf denselben zugrunde liegenden Daten operieren.

Für Teams, die operative Daten parallel zu Analysen verwalten, erweitern neue Architekturen wie Databricks Lakebase diesen Ansatz, indem sie transaktionale und analytische Workloads auf einer gemeinsamen Datenplattform vereinheitlichen. Dies reduziert Datenbewegungen und vereinfacht den Datenzugriff über Systeme hinweg.

Ist eine Lakebase-Architektur das richtige Serverless Postgres für Sie?

Serverless Postgres vereinfacht den Datenbankbetrieb, indem es einen Großteil des Infrastrukturmanagements überflüssig macht und die Kosten enger an der tatsächlichen Nutzung ausrichtet. Da Compute und Storage entkoppelt sind, passen sich die Ressourcen an den Bedarf an. Für Teams mit anspruchsvolleren Workloads erweitert die Lakebase-Architektur dieses Fundament noch weiter.

Diese Kompromisse sollten sorgfältig abgewogen werden. Die Vorhersehbarkeit der Performance, die Kosten bei Skalierung sowie Faktoren wie Kaltstart-Latenz und Verbindungsmanagement variieren je nach Workload.

Die Wahl des Anbieters ist entscheidend. Unterschiede beim Kaltstartverhalten, bei den Preismodellen, der Skalierungsgranularität und der Ökosystem-Kompatibilität können die Ergebnisse erheblich beeinflussen. Für Analytik- und Data-Engineering-Workloads bieten Plattformen wie Databricks SQL eine serverlose Abfrageausführung. Teams können außerdem im Rahmen der Produkttour zu Databricks Lakebase erkunden, wie sich dieses Modell auf operative Workloads ausweiten lässt.

Da sich Datenbankarchitekturen ständig weiterentwickeln, vereint die Lakebase-Architektur operative und analytische Workloads auf einer gemeinsamen Datengrundlage.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag