Das Wesentliche
Aurabase: Postgres 16-Datenbank pro Projekt dediziert, Berechnung nie ausgesetzt, natives RLS, integriertes NL2SQL/RAG, Infrastruktur in Deutschland und Finnland verifiziert. Neon: Berechnung, die auf Null skaliert und bei Bedarf aktiviert wird, 2025 von Databricks (amerikanisches Unternehmen) gekauft, Copy-on-Write-Verzweigung nützlich für die Entwicklung. Wenn Ihre Priorität die sofortige Verfügbarkeit und rechtliche Souveränität eines Produktions-Backends ist, geht die Aurabase-Architektur direkt auf diesen Bedarf ein.
Ein Computer, der niemals schläft
Aurabase stellt pro Projekt eine dedizierte Postgres 16-Datenbank bereit, die nie zwischen Clients geteilt wird, ohne dass die Rechenleistung angehalten werden muss: Ihr Backend antwortet ab der ersten Anfrage, nachts, an Wochenenden oder nach einer Nebensaison – ohne zu absorbierende Aktivierungslatenz.
Neon basiert auf einer Architektur, die Rechenleistung und Speicher trennt und die Rechenleistung aufgrund von Inaktivität in den Ruhezustand versetzt, um die Kosten zu senken. Dies ist eine konsequente Wahl für eine Entwicklungs- oder Testumgebung, die die meiste Zeit im Leerlauf ist – aber jedes Aufwachen führt zu einer Wiederaufnahmelatenz, die Ihr erster Benutzer am Morgen direkt absorbiert.
Die Frage, die eine Verzweigung nicht beantwortet: Wo ist Ihre Muttergesellschaft?
Neon wurde 2025 von Databricks, einem amerikanischen Unternehmen, übernommen. Ein amerikanisches Mutterunternehmen unterliegt weiterhin dem CLOUD Act, unabhängig von der Region, in der Ihre Daten physisch laufen – ein rechtlicher Mechanismus, der unabhängig von der geografischen Lage des Servers ist.
Aurabase SAS ist ein Unternehmen nach französischem Recht mit einer geprüften Produktionsinfrastruktur vollständig in der EU (Nürnberg, Falkenstein, Helsinki über Hetzner). Kein Kontrollkästchen für die Region, das aktiviert werden muss, um im Nachhinein zu kompensieren: Die Nationalität des Lieferanten und der Standort des Datenpunkts stimmen von Anfang an in derselben Richtung überein.
Was Neon besser macht – und warum es in der Produktion nicht ausreicht
Die Copy-on-Write-Verzweigung von Neon erstellt in weniger als einer Sekunde eine isolierte Postgres-Instanz aus einer gemeinsam genutzten übergeordneten Instanz – ein echter Gewinn für eine Pull-Request-Vorschauumgebung. Aurabase hat bisher kein Äquivalent.
Bei einem Produktions-Backend geht es jedoch nicht nur um verfügbare Zweige: Es benötigt natives RLS für die Isolation mehrerer Mandanten, natives NL2SQL für KI-Funktionen und eine Verfügbarkeit, die nicht vom Aufwecken der Rechenleistung abhängt. Hier erfüllt die Aurabase-Architektur – permanent dediziertes Postgres, RLS und native KI im selben Kern – einen Bedarf, den die Verzweigung allein nicht abdeckt.
Native Suche und Analyse: ein schmales Unterscheidungsmerkmal, keine vollständige Plattform
Xata fügt Volltextsuche, Vektorsuche und Analysen (über pg_cron und materialisierte Ansichten) direkt zu Postgres hinzu, um die Zusammenstellung eines separaten OLAP-Stacks zu vermeiden. Dies ist eine technische Nischenpositionierung, kein vollständiges BaaS: keine integrierte Authentifizierung, keine Echtzeit, keine Edge-Funktionen.
Aurabase deckt nativ pgvector, RAG und NL2SQL ab – umfassender als Xata-Suche/Analyse – in einer Plattform, die auch Authentifizierungs-, Speicher-, Echtzeit- und Rust/WASM-Edge-Funktionen umfasst. Sehen Sie sich unser RAG-Pipeline-Tutorial mit pgvectoran.
Was unterscheidet die drei Architekturen?
| Verfügbarkeit | Dediziertes Computing, niemals ausgesetzt | Rechenleistung aufgrund von Inaktivität unterbrochen (Neon) |
|---|---|---|
| Muttergesellschaft | Aurabase SAS, französisches Recht | Databricks, amerikanisches Recht (Neon) |
| Verzweigung | Bisher keine Entsprechung | Copy-on-Write in weniger als einer Sekunde (Neon) |
| Native KI | pgvector + RAG + NL2SQL integriert | Vektorsuche + Analyse (Xata) |
| Plattform | Auth, DB, Echtzeit, Speicher, Edge, KI | Nur Datenbank (Neon, Xata) |