Databricks übernimmt Neon, Spezialist für serverloses Postgres

• Databricks hat eine Vereinbarung zur Übernahme von Neon getroffen, das entwicklerzentriertes serverloses Postgres anbietet
• Neon bietet über eine Architektur mit getrennter Storage- und Compute-Ebene eine serverlose Datenbankplattform, die für Entwickler und AI-Systeme optimiert ist
• Mit der Einführung von Neon ist der Anteil der von AI-Agenten erzeugten Datenbanken rasant von 30 % auf über 80 % gestiegen
• Databricks und Neon teilen eine Open-Source-Philosophie und eine DNA der Infrastrukturinnovation
• Auch nach der Übernahme sollen der Support für die Neon-Plattform und die zukunftsorientierte Roadmap durch die Ressourcen von Databricks gestärkt werden

---

Bekanntgabe der Übernahme und ihre Bedeutung

• Databricks hat eine Vereinbarung zur Übernahme von Neon getroffen, das entwicklerzentriertes serverloses Postgres anbietet
• Die Mitgründer von Neon gehören zu den wenigen Experten weltweit, die Postgres mit einer vollständig getrennten Storage- und Compute-Architektur entwerfen können
• Dieses Team hat sich darauf konzentriert, eine serverlose Postgres-Plattform für die Unterstützung großer Entwicklerzahlen im AI-Zeitalter bereitzustellen

Innovationsmission rund um Postgres

• Die Mitgründer von Neon kamen vor rund vier Jahren zusammen, um veraltete Datenbankarchitekturen zu erneuern
• Die zentralen Ziele waren wie folgt
  • Sie prognostizierten die faktische Standardisierung von Postgres und entwickelten die Vision einer serverlosen Plattform
  • Der Fokus lag auf Geschwindigkeit, damit Entwickler in wenigen Sekunden neue Instanzen erstellen können
  • Durch automatische Skalierung der Datenbank und die Vereinfachung von Abläufen sollten Sorgen vor Über- und Unterprovisionierung beseitigt werden
  • Mit sofortiger Unterstützung für Branching und Forking sollten Datenbanktests und Experimente erleichtert werden
• Das Neon-Team erreichte diese Ziele mit einer Architektur, bei der Storage und Compute unabhängig voneinander skalieren können
• Seit dem Launch loben Entwickler die Geschwindigkeit, die Einfachheit und die Git-artigen Branching-/Forking-Funktionen

Veränderungen im Zeitalter der AI-Agenten

• Seit dem GA von Neon machten AI-Agenten 30 % aller DB-Erstellungen aus, zuletzt stieg dieser Anteil auf über 80 %
• AI-Agenten haben inzwischen ähnliche Anforderungen wie Entwickler
• Zu den Stärken von Neon zählen
  • Das Open-Source-Ökosystem von Postgres: Moderne LLMs wurden mit Postgres-Daten trainiert, weshalb AI-Agenten den Einsatz von Neon gut beherrschen
  • Hohe Geschwindigkeit: Da höhere Geschwindigkeit als beim Menschen erforderlich ist, ist ultraschnelle Instanzbereitstellung essenziell
  • Flexible Skalierung und Preisgestaltung: Durch die getrennte serverlose Architektur sind sehr niedrige Kosten und die Unterstützung vieler AI-Agenten möglich
  • Branching und Forking: Experimente und Validierung für die sprunghaften Versuche von AI-Agenten werden einfacher

Die gemeinsame DNA von Databricks und Neon

• Die Gründer Nikita Shamgunov, Heikki Linnakangas und Stas Kelvich sind in der Branche bekannte Experten für Datenbanktechnologie
• Sie verfügen jeweils über umfangreiche Erfahrung und Originalität, etwa bei SingleStore oder als Postgres-Committer
• Sowohl Databricks als auch Neon legen großen Wert auf technologische Spitzeninnovation auf der Infrastrukturebene und Open-Source-Werte
• Apache Spark und Postgres verbindet zudem, dass beide als Open-Source-Projekte an der UC Berkeley entstanden sind

Zukünftige Vision und Nutzen für Anwender

• Der OLTP-Datenbankmarkt (mit einem Volumen von rund 100 Milliarden US-Dollar) wird derzeit von Produkten aus vergangenen Jahrzehnten geprägt
• Jetzt ist der Zeitpunkt gekommen, an dem Entwickler und AI-Agenten die Innovation vorantreiben
• Databricks und Neon streben die entwicklerfreundlichste und AI-Agenten-freundlichste DB-Plattform an
• Bestehende Neon-Kunden und -Partner können weiterhin mit Support und Innovation sowie der Umsetzung der Roadmap rechnen
• Mit den Ressourcen von Databricks sollen eine Stärkung der Plattform und stabiles Wachstum sichergestellt werden
• Auf dem Data + AI Summit (San Francisco, 9.–12. Juni) soll die weitere Vision ausführlich vorgestellt werden

[GN⁺]

Hacker-News-Kommentare

• Ich denke, Data Warehousing wird dank Open Source sehr schnell zur Commodity. Eine Firma, die ich kenne, hatte über 2 Petabyte an Daten in Cloudera gespeichert, ist aber nicht in die Cloud (Databricks) umgezogen, sondern hat mit Iceberg, Trino und Superset eine eigene Analyseplattform aufgebaut und dabei die Kosten um das Fünffache gesenkt. Enterprise-taugliche k8s-Operatoren sind inzwischen gut genug, und On-Premises-S3 ist ebenfalls hervorragend. Gute Hardware und Netzwerke sind auch machbar, etwa Server mit 128 CPUs und 1 TB RAM. Nicht nur Trino, sondern auch StarRocks und ClickHouse bieten Enterprise-taugliche k8s-Helm-Charts/Operatoren. Die Unternehmensbewertung von Databricks von 60 Milliarden Dollar ist deren Problem. Sie müssen diesen Preis rechtfertigen, und selbst ihr Kerngeschäft wird zur Commodity. Neon schließt die Lücke in ihrem Produktportfolio, in dem bislang eine operative (zeilenorientierte) DB fehlte
  • Aus Enterprise-Sicht ist das keine Commodity. Mein früherer Arbeitgeber erlaubte weder Open-Source-Software noch Firmen, die in zehn Jahren vielleicht nicht mehr existieren, noch Unternehmen, die unsere Daten außerhalb unseres eigenen Tenants speichern. Ein Preismodell nach dem Motto „Preis auf Anfrage“ wurde sogar begrüßt, und die Einführung von Databricks zählt zu meinen drei größten Erfolgen, weil wir uns um die Datenplattform nicht mehr kümmern mussten. Das Risiko bei der Einführung neuer Plattformen ist einfach zu groß, daher ist (beliebiges Open-Source-Projekt) nicht vertrauenswürdig. Wir haben einmal eine Startup-Lösung eingeführt, die MongoDB nutzte, und weil dem Betriebsteam die Fähigkeiten fehlten, haben wir statt Lernaufwand lieber einen voll unterstützten Service wie Atlas eingekauft. Statt einer unbekannten Azure-Firewall nutzten wir nur Firewalls, die wir kannten, und kümmerten uns um alle möglichen Verträge. Weniger Personalbedarf, nur ein Ansprechpartner, mehr Effizienz. Eine Startup-Lizenz kostet vielleicht 5–10K Dollar pro Jahr, aber Support verschlingt leicht 40K Dollar oder mehr. Startup und Enterprise sind völlig verschiedene Welten
  • Ich nutze Open-Source-StarRocks mit einem k8s-Operator für Kundenanalysen im Terabyte-Bereich, und in meiner Umgebung fühlt sich Databricks fast überflüssig an
  • Ich nutze ClickHouse seit einigen Jahren problemlos. Sehr breites Funktionsspektrum und eine vertrauenswürdige Datenbank. Dank der Funktion für externe Dictionaries ist die Integration mit anderen Datastores wie Postgres oder Redis einfach
  • Falls jemand eine Open-Source-Alternative zu Cloudera auf Basis von Kubernetes-Operatoren sucht: Ich entwickle seit fünf Jahren stackable.tech. Beim Thema On-Premises Open-Source-S3 ist die Lage problematisch. MinIO würde ich nicht empfehlen, und darüber hinaus gibt es kaum Lösungen, die enterprise-tauglich sind
  • Data Warehousing ist schon seit Jahrzehnten zur Commodity geworden. Es gibt eine lange Geschichte von Preis- und Performance-Metriken, und die SnowBricks-Produkte werden dem nicht gerecht. Es ist nur der Unterschied zwischen Hard Sell und Soft Sell
  • Ich verstehe nicht, warum man bei Databricks eine operative DB kaufen sollte. Für mich sieht das nur nach Databricks’ Kampf aus, die eigene Marktbewertung zu stützen
  • Wenn Databricks einfach nur eine Row-DB gebraucht hätte, hätten sie Postgres selbst aufgebaut. Dass sie so viel Geld für Neon ausgeben, ist ein Signal, dass sie etwas Besonderes wollten, etwa Neons „unabhängig skalierbaren Storage und Compute“
  • Mich würde interessieren, was ihr für ETL verwendet
• Ich habe mich letzte Woche bei neon beworben, und nachdem die Übernahme bekannt wurde, kam heute Morgen sofort die Absage. Noch nie war ich so glücklich über eine Absage. Es wäre das dritte Mal in Folge gewesen, dass ich fast bei einer Firma anfange, die übernommen wird, also will ich jetzt einfach nur Stabilität. Glückwunsch an das neon-Team. Ich mag neon und nutze es, und ich hoffe, dass sich durch diese Übernahme nicht zu viel verändert
  • Ich bin vor einer Übernahme bei Kenna Security eingestiegen, und einen Monat später wurden sie von Cisco übernommen. Das war eine wirklich schreckliche Erfahrung, und ich würde weder wieder bei einer Firma mit Kenna-Führungskräften arbeiten noch bei Cisco
  • Ich habe eher die gegenteilige Erfahrung gemacht. Der Zeitpunkt einer Übernahme war der spannendste, um einzusteigen. In meinem Fall wurde ich wegen meiner Erfahrung mit Post-Merger-Integration später oft abgeworben
  • Als ich im ersten Jahr Engineering Manager war, habe ich eine Übernahme miterlebt. Ich habe zwei Entlassungswellen durchgestanden, mitentschieden, wer bleiben durfte, und bei der Umstrukturierung von Teams geholfen. Die Moral war am Boden, und die Unternehmenskulturen passten überhaupt nicht zusammen. Ich hatte ein heftiges Burnout, habe ein paar Monate pausiert und arbeite jetzt wieder glücklich als IC
  • Meine Vermutung ist, dass das neon-Team in Databricks’ Online-Tables-Technologie integriert wird. Das ergibt auch produktseitig Sinn
  • Wenn man noch zu einer alten neon-Bewertung eingestiegen ist und das Vesting gerade abgeschlossen war, hätte man jetzt wohl plötzlich eine größere Summe bekommen — ich frage mich, wie sich das anfühlt
• Databricks ist die nervigste Schrottsoftware, die ich je benutzt habe. Ich frage mich, wer das freiwillig verwendet
  • Databricks startete 2013, als Spark noch ziemlich schlecht war, und hat Spark besser und schneller gemacht. Das Produkt ist immer noch stark Spark-zentriert, aber ich denke, eine Kombination aus Iceberg und DuckDB passt für 95 % der Unternehmen besser. Günstiger, schneller, einfacher zu handhaben, und genau auf dieser Annahme bauen wir bei Definite auch unsere Datenplattform auf, inklusive ETL, BI und Data Lake
  • Databricks ist das Jira der Datenwelt. Niemand will es benutzen, es ist nicht besonders gut, und weil es für alle Nutzer alles sein wollte, wirkt jede einzelne Funktion halbgar. Es gibt inzwischen viel bessere Alternativen, deshalb würde ich Databricks nie freiwillig wählen
  • Dem kann ich wirklich kaum zustimmen. Aus meiner Hadoop-Perspektive ist Databricks eine Utopie. Stabil, schnell und hervorragend skalierbar für große Datensätze. Mein größter Kritikpunkt ist nur, dass es viel zu teuer ist
  • Ich mochte die Databricks-Plattform früher. 2020–2021 war Databricks gegenüber AWS, Azure und Snowflake fast die einzige halbwegs vernünftige Alternative. Heute ist es wegen Feature-Flut, ständigen Änderungen und Übernahmen völlig unübersichtlich, und selbst die Namen der Funktionen sind chaotisch
  • Offenbar gibt es also immer noch einen Markt für Software im IBM-Stil („alle benutzen das, also tun wir das auch“)
  • Ehrlich gesagt ist Databricks ein sehr langweiliges Produkt. Wenn ich an die späten 2010er zurückdenke, war Spark-as-a-Service hervorragend, in einer Zeit, in der Unternehmen daran scheiterten, Spark selbst stabil zu betreiben. Auch die Hyperscaler hatten damals schwache First-Party-Angebote. Es gab zwar Probleme wie die Jupyter-Kompatibilität des Databricks-Notebook-Formats, aber instabile On-Prem-Cluster waren das größere Problem, sodass man die Prämie gern bezahlte. Damals war Databricks ein großartiges Milliarden-Business. Aber allein mit Spark-aaS konnte man kein Unicorn werden. AWS EMR kam als Konkurrent langsam näher, und schließlich setzte Databricks alles auf aufgeblähte Produkte und Wachstumsstrategie: Daten, Lake, House als Buzzword-Dauerfeuer. Im Jahr 2025 ist der Niedergang von Databricks ein bitteres Beispiel für Enshittification. Vielleicht wird Larry Ellison die Firma irgendwann kaufen und vom Markt verschwinden lassen. Ich verstehe nicht, warum man Databricks heute noch für neue Projekte auswählt, aber Enterprises, die es seit über fünf Jahren nutzen, kommen nicht so leicht davon los. Der Marktanteil wird wohl sinken, aber Geld werden sie noch eine Weile verdienen. So läuft der Zyklus der Branche, und am Ende gewinnt die Entropie. Ich werde sie nicht zu sehr hassen. Sie haben eine ziemlich gute Geschichte geschrieben
  • Serverless wird viel zu stark betont, aber die Grenzen und versteckten Fallstricke sind so zahlreich, dass es wirklich wahnsinnig anstrengend ist
  • Ich frage mich, ob gehostetes Spark wirklich so revolutionär war. Und ich habe immer gezweifelt, ob Spark selbst für 90 % der etablierten Unternehmens-Datenverarbeitung nicht viel zu komplex ist. Ich verstehe nicht, warum diese Firma so viel wert sein soll
  • Wenn man Cookies deaktiviert, lädt die Website überhaupt nicht. Das ist eine massive Red Flag. Von einer Firma, die nicht einmal eine Website ordentlich bauen kann, erwarte ich kein gutes digitales Produkt
• Databricks ist so schlecht wie Oracle. Ich bin sicher, dass sie Neon ruinieren oder teuer machen werden. Mittel- bis langfristig werde ich nach Alternativen zu Neon suchen
  • Databricks’ M&A-Strategie ist darauf ausgelegt, übernommene Firmen zu ersticken. Gleichzeitig tut man sich schwer mit der tektonischen Verschiebung durch Open Source wie Iceberg und DuckDB. Man versucht zwar, über Übernahmen Innovation zu erreichen, aber wegen der Unternehmenskultur brechen die übernommenen Firmen auseinander. Ich komme aus der Big-Data-Branche, früher bei Snowflake, also bin ich vielleicht voreingenommen, aber es ist klar zu sehen, dass Open Source immer stärker wird. Ich bin sehr gespannt, wie sich das entwickelt
• Zitat aus dem Originalartikel: „Als Neon letztes Jahr GA wurde, wurden 30 % der Datenbanken von AI-Agenten erstellt; als wir kürzlich wieder nachgesehen haben, lag dieser Anteil bei über 80 %. Das heißt, AI hat viermal mehr Datenbanken erstellt als Menschen.“ Das ist eine Kennzahl, bei der gleich mehrere Alarmglocken läuten. Es wirkt, als wolle Databricks Postgres als AI-Lösung verpacken. Wirklich seltsame Zeiten
  • Ich frage mich, wie viele davon tatsächlich aktiv genutzt werden
• Glückwunsch an das Neon-Team. Ich mag sehr, was ihr gebaut habt. Aber ehrlich gesagt sehe ich keine wirkliche Verbindung oder Synergie mit Databricks und hoffe, dass Neon als separates Produkt bestehen bleibt. Sonst verliert der Markt einen klaren Postgres-Anbieter
  • Wegen der starken Azure-Abhängigkeit wird es wohl nicht sofort verschwinden. Es sieht eher danach aus, dass Databricks nicht nur bei Analyse-DBs, sondern auch bei Transaktions-DBs expandieren will
  • In den FAQ steht zwar, dass Neon unabhängig betrieben wird, aber ich denke, das Ergebnis ist offensichtlich
• Ich erinnere mich an den ersten HN-Post des Neon-Teams. Damals habe ich schon kommentiert, dass es eine großartige Idee sei. Ich hatte bisher noch keinen direkten Bedarf, dachte aber immer, dass ich es irgendwann nutzen würde. Wenn ich jetzt solche Übernahme-News sehe, macht mich das skeptisch. Ich befürchte, dass der Fokus nun eher auf Eigentümern als auf Nutzern liegt. Theoretisch sollten diese Interessen übereinstimmen, aber in der Praxis war das selten der Fall
  • Ich erinnere mich ebenfalls an den ersten Neon-Post. Die Trennung von Storage und Compute war frisch und spannend, und ich hatte damals auch Fragen zum Pageserver gestellt. Zwei Jahre später arbeite ich nun selbst bei Turso database an einer ähnlichen Entkopplung des Storage. Nochmals Glückwunsch an das Neon-Team
  • Auch ich habe bei der Übernahme erst einmal gestutzt. Dass der Fokus auf AI-Nutzern liegt, passt meiner Meinung nach nicht automatisch zu den Interessen von Entwicklern. Ich hoffe, dass die Technologien rund um den PostgreSQL-Kern der Open-Source-Community zugutekommen
• Glückwunsch an das Neon-Team. Ein großartiges Produkt. Natürlich halte ich so ein Ergebnis bei VC-finanzierten Firmen für unvermeidlich. Ich hoffe, dass Nikita und die anderen in Databricks nicht assimiliert werden und standhaft bleiben
• Das ist wirklich eine interessante Entwicklung. Ich halte diese Art der Konvergenz von OLTP und OLAP für den richtigen Weg. Ich habe zusammen mit dem OP bei SingleStore an einem HTAP-System gearbeitet. Wir wollten OLTP und OLAP in einer einzigen Datenbank vereinen, die mit einer einzigen Kopie beides unterstützt, aber HTAP hat nicht gut funktioniert. OLTP sollte auf Postgres laufen, OLAP auf einem Data Warehouse/Lake, und die Replikation dazwischen muss effizient entworfen sein. Synchrone Replikation ist schwierig. Ein spaltenorientierter Speicher kann OLTP-Schreibvorgänge nicht gut aufnehmen. Ich bin gespannt, ob Databricks und Neon das Szenario umsetzen können, in dem „aktuelle Postgres-Tabellen direkt im Unity Catalog genutzt werden“, ohne Debezium, Kafka, Flink oder Iceberg dazwischen, während Spark den Iceberg-Status verwaltet
  • Ist mit OP Neon-Gründer Nikita Shamgunov gemeint, der früher MemSQL/SingleStore gegründet hat?
• Glückwunsch an das Neon-Team. Ehrlich gesagt bin ich etwas enttäuscht. Ich hatte gehofft, dass Neon die Lücke füllt, die CockroachDB mit dem Wechsel auf Business Source hinterlassen hat. Durch die Übernahme durch Databricks wirkt Neon auf mich weniger attraktiv. Es fällt mir schwer zu glauben, dass ein Großunternehmen wichtige Infrastruktur verantwortungsvoll betreiben wird. Die Nachfrage nach einem „modernen“ PostgreSQL ist groß, aber keine der Alternativen entfernt sich wirklich von den Grundproblemen, sei es bei Preis, Kompatibilität oder Offenheit des Quellcodes. Bei der Suche nach Postgres-Alternativen habe ich Folgendes verglichen
  (1) AWS RDS nutzten wir bereits, aber es war teuer und hatte Skalierungs- und Betriebsprobleme
  (2) AWS Aurora löst einige Betriebsprobleme, bringt aber andere Nachteile mit sich und hat ähnliche Grenzen wie andere wire-kompatible Postgres-Alternativen
  (3) CockroachDB war sehr interessant, hatte aber Toolchain- und tiefgehende Kompatibilitätsprobleme; damals war es noch Open Source
  (4) Neon wirkte noch unausgereift, deshalb haben wir es nicht eingeführt, aber es war spannend und schien viele Probleme lösen zu können
  (5) Yugabyte war ebenfalls technisch interessant, hatte aber verschiedene Kompatibilitätsprobleme
  Wir haben auch darüber nachgedacht, Postgres selbst zu hosten, aber der Eigenbetriebsaufwand für Kubernetes und Postgres war zu hoch. Eigene Replikations- und Betriebsfunktionen waren noch nicht ausgereift, und bei Upgrades war das vollständige Entladen und erneute Laden aller Daten sehr mühsam. Skalierung und Automatisierung waren nicht einfach
  • Als Reaktion auf den Vergleich mit Yugabyte, dessen Query Engine wohl auf Postgres basiert: Zur Erinnerung, Neon ist Postgres
  • Jemand teilt seine kurzfristige Erfahrung mit dem Satz: „Die beste moderne Postgres-Alternative ist Postgres selbst — in fünf Jahren“
  • Ich würde gern mehr darüber hören, was genau die „gleichen Nachteile“ bei anderen wire-kompatiblen PostgreSQL-Alternativen sind