Aurora PostgreSQL verbindet Live-Daten mit S3
Amazon Web Services erweitert Aurora PostgreSQL um direkte Abfragen auf historische Daten in Amazon S3. Aktuelle Datensätze aus der laufenden Datenbank lassen sich dadurch in einer einzigen SQL-Abfrage mit Apache-Iceberg-Tabellen oder Parquet-Dateien kombinieren.
Apache Iceberg ist ein offenes Tabellenformat für große analytische Datenbestände. Parquet speichert Daten spaltenorientiert und eignet sich damit besonders für Auswertungen. Die externen Daten müssen vor der Abfrage nicht nach Aurora kopiert oder über separate Prozesse synchronisiert werden.
Anwendungen können ihre bestehenden PostgreSQL-Verbindungen weiterverwenden. Ein typischer Anwendungsfall ist die Verknüpfung aktueller Transaktionen in Aurora mit älteren Geschäftsdaten, die kostengünstiger in S3 archiviert sind.
DuckDB übernimmt die analytischen Abfragen
Für den Zugriff auf den Data Lake setzt AWS eine direkt in Aurora eingebettete DuckDB-Engine ein. DuckDB ist eine für analytische SQL-Abfragen optimierte Datenbank. Amazon hat Duck Labs, das Unternehmen hinter dem Projekt, kürzlich übernommen.
Unterstützt werden Iceberg-Tabellen im AWS Glue Data Catalog sowie Iceberg- und Parquet-Daten in S3 und S3 Tables. Bestehende externe Kataloge mit Iceberg-REST-Schnittstelle lassen sich über AWS Glue anbinden.
In Aurora werden die externen Bestände als Foreign Tables eingebunden. Dabei handelt es sich um Tabellendefinitionen, die nicht auf lokalen Daten, sondern auf einer externen Quelle basieren. Bei Parquet-Dateien kann Aurora das Schema aus den gespeicherten Metadaten auslesen und mehrere Tabellen über IMPORT FOREIGN SCHEMA anlegen.
Voraussetzungen und Verfügbarkeit
| Bereich | Voraussetzung |
|---|---|
| Aurora PostgreSQL 17 | Version 17.11 oder neuer |
| Aurora PostgreSQL 18 | Version 18.6 oder neuer |
| Serverless | Aurora Serverless v2 wird unterstützt |
| Regionen | Alle kommerziellen AWS-Regionen sowie GovCloud US |
| Funktionsaufschlag | 0 €, reguläre Compute- und S3-Kosten fallen weiterhin an |
Administratoren müssen dem Aurora-Cluster eine IAM-Rolle mit der Funktion AuroraAnalytics zuweisen und die Erweiterung aurora_analytics aktivieren. Über die Rolle werden die Zugriffsrechte für S3 und den AWS Glue Data Catalog gesteuert.
Die Abfragen können auf der Writer-Instanz oder auf Read Replicas ausgeführt werden. Aurora versucht, nur die benötigten Spalten und Datenbereiche aus S3 zu lesen. Häufig verwendete Daten können außerdem im Cache der Instanz verbleiben.
Kosten verschieben sich vom Speicher zur Nutzung
AWS berechnet für die Funktion selbst keinen Aufpreis. Kosten entstehen jedoch durch die zusätzliche Rechenlast in Aurora und durch reguläre S3-Leseanfragen. Bei großen oder häufig wiederholten Abfragen kann die tatsächliche Rechnung deshalb deutlich vom reinen Speicherpreis des Data Lakes abweichen.
| Kostenblock | Abrechnung |
|---|---|
| Aurora-Integration | Kein direkter Aufpreis |
| Aurora-Rechenleistung | Nach regulärem Aurora-Tarif |
| S3-Zugriffe | Standardmäßige Kosten für Leseanfragen |
| S3-Speicher | Nach gewählter Speicherklasse und Datenmenge |
Für Kostenkontrollen stellt die Erweiterung Kennzahlen zu gelesenen S3-Daten und Cache-Treffern bereit. Belastbare Angaben zur Leistung gegenüber vollwertigen Data Warehouses oder selbst betriebenen Lösungen mit DuckDB beziehungsweise ClickHouse liegen bislang nicht vor. Offen bleibt auch, wie sich massive parallele Scans auf Latenz und Stabilität auswirken.
Weniger ETL, aber stärkere AWS-Bindung
Für Unternehmen im DACH-Raum ist die Funktion unter anderem in den AWS-Regionen Frankfurt und Zürich verfügbar. Historische Bestände können damit im Objektspeicher verbleiben, während Berichte oder Compliance-Abfragen weiterhin über PostgreSQL erfolgen. Das kann einen zusätzlichen Data-Warehouse-Stack und aufwendige ETL-Pipelines reduzieren.
Die offenen Formate Parquet und Iceberg erleichtern grundsätzlich einen späteren Wechsel der Auswertungsplattform. Die konkrete Einbindung über aurora_analytics, IAM und AWS Glue ist jedoch proprietär. Damit sinkt die Abhängigkeit auf Datenformatebene, während sie auf Infrastruktur- und Betriebsebene zunimmt.
Gerade bei langfristig gespeicherten Unternehmensdaten bleiben deshalb Export-, Backup- und Wiederanlaufkonzepte notwendig. Der endgültige Datenverlust in AWS-Regionen zeigt, warum ein verwalteter Dienst keine eigene Sicherungsstrategie ersetzt. Auch die wachsende Suche nach Alternativen zu stark gebundenen Plattformen unterstreicht den wirtschaftlichen Wert portabler Daten und austauschbarer Komponenten.
Die Aurora-Erweiterung ist damit vor allem für bestehende AWS-Architekturen interessant. Sie kann Datenkopien und zusätzliche SaaS-Kosten vermeiden, sollte aber anhand realer Abfragemuster getestet werden. Entscheidend sind nicht nur Speicherpreise, sondern auch Compute-Kosten, S3-Zugriffe und der Aufwand für einen späteren Plattformwechsel.