Databricks acquiert Neon, spécialiste du Postgres serverless

• Databricks a conclu un accord pour acquérir Neon, qui propose un Postgres serverless centré sur les développeurs
• Neon fournit une plateforme de base de données serverless optimisée pour les développeurs et les systèmes d’IA grâce à une architecture séparant stockage et calcul
• Avec l’adoption de Neon, la part des bases de données générées par des agents IA a connu une croissance fulgurante, passant de 30 % à plus de 80 %
• Databricks et Neon partagent une philosophie open source et un ADN d’innovation dans l’infrastructure
• Après l’acquisition, le support de la plateforme Neon et sa feuille de route tournée vers l’avenir seront renforcés par les ressources de Databricks

---

Annonce de l’acquisition et son importance

• Databricks a conclu un accord pour acquérir Neon, qui propose un Postgres serverless centré sur les développeurs
• Les cofondateurs de Neon font partie des rares experts au monde capables de concevoir Postgres avec une séparation complète entre stockage et calcul
• Cette équipe s’est concentrée sur la fourniture d’une plateforme Postgres serverless pour accompagner les développeurs à grande échelle à l’ère de l’IA

Mission d’innovation autour de Postgres

• Les cofondateurs de Neon se sont réunis il y a environ quatre ans avec l’ambition de moderniser une architecture de base de données devenue obsolète
• Les objectifs clés étaient les suivants
  • Anticiper la standardisation de fait de Postgres et bâtir une vision de plateforme serverless
  • Mettre l’accent sur la rapidité afin que les développeurs puissent créer une nouvelle instance en quelques secondes
  • Favoriser l’autoscaling de la base de données et simplifier les opérations pour réduire les inquiétudes liées au surprovisionnement ou au sous-provisionnement
  • Permettre la création instantanée de branches et de forks afin de faciliter les tests et les expérimentations sur les bases de données
• L’équipe Neon a atteint ces objectifs en créant une architecture permettant une mise à l’échelle indépendante du stockage et du calcul
• Depuis le lancement, les développeurs saluent sa rapidité, sa simplicité et ses fonctionnalités de branching/forking à la Git

Les changements à l’ère des agents IA

• Depuis la disponibilité générale de Neon, les agents IA représentaient 30 % de l’ensemble des créations de bases de données, et ce chiffre est récemment passé à plus de 80 %
• Les agents IA ont désormais des besoins similaires à ceux des développeurs
• Les points forts de Neon sont les suivants
  • Écosystème open source Postgres : les LLM les plus récents ont été entraînés sur des données Postgres, ce qui rend les agents IA à l’aise avec Neon
  • Rapidité : des vitesses supérieures à celles des humains étant requises, un provisionnement ultra-rapide des instances est indispensable
  • Évolutivité flexible et tarification : grâce à une architecture serverless dissociée, les coûts sont très faibles et il est possible de prendre en charge un grand nombre d’agents IA
  • Branching et forking : les expérimentations et validations deviennent plus simples pour accompagner les tentatives changeantes des agents IA

L’ADN partagé de Databricks et de Neon

• Les fondateurs Nikita Shamgunov, Heikki Linnakangas et Stas Kelvich sont des experts reconnus des technologies de bases de données
• Ils disposent chacun d’une solide expérience et d’une forte créativité, notamment chez SingleStore et parmi les committers de Postgres
• Databricks et Neon accordent tous deux une grande importance à l’innovation de pointe dans la couche infrastructure et aux valeurs de l’open source
• Apache Spark et Postgres ont aussi en commun d’être des projets open source nés à UC Berkeley

Vision à venir et bénéfices pour les utilisateurs

• Le marché des bases de données OLTP, estimé à environ 100 milliards de dollars, reste aujourd’hui dominé par des produits conçus il y a plusieurs décennies
• Le moment est venu pour les développeurs et les agents IA de porter l’innovation
• Databricks et Neon visent à bâtir la meilleure plateforme de base de données pour les développeurs et adaptée aux agents IA
• Les clients et partenaires actuels de Neon peuvent s’attendre à un support continu et à une innovation continue, ainsi qu’à la concrétisation de la feuille de route
• Grâce aux ressources de Databricks, un renforcement de la plateforme et une croissance stable sont prévus
• La vision à venir sera présentée en détail lors du Data + AI Summit (San Francisco, du 9 au 12 juin)

[GN⁺]

Réactions sur Hacker News

• J’ai l’impression que le data warehousing se banalise rapidement grâce à l’open source. Une entreprise que je connais stockait plus de 2 pétaoctets de données sur Cloudera, mais au lieu de migrer vers le cloud (Databricks), elle a construit sa propre plateforme d’analyse avec Iceberg, Trino et Superset, et a réduit ses coûts d’un facteur 5. Les opérateurs k8s de niveau enterprise sont désormais suffisamment bons, et le S3 on-premise est excellent. On peut aussi avoir du très bon matériel et réseau, avec par exemple des serveurs à 128 CPU et 1 To de mémoire. En plus de Trino, StarRocks et ClickHouse proposent aussi des charts Helm/opérateurs k8s de niveau enterprise. La valorisation de Databricks à 60 milliards de dollars, c’est leur problème. Ils doivent justifier ce prix, alors même que leur cœur de métier se banalise lui aussi. Neon comble un trou dans leur gamme, qui n’avait pas de base de données opérationnelle (orientée lignes)
  • Du point de vue enterprise, ce n’est pas banalisé. Mon ancien employeur n’autorisait ni les logiciels open source, ni les entreprises qui pourraient ne plus exister dans 10 ans, ni les sociétés qui stockent les données ailleurs que dans notre tenant. On accueillait même favorablement les politiques tarifaires “nous contacter”, et adopter Databricks fait partie de mes trois plus grandes réussites parce qu’on n’avait plus à se soucier de la plateforme data. Le risque lié à l’adoption d’une nouvelle plateforme est trop élevé, donc impossible de faire confiance à (n’importe quel projet open source). Une fois, on a adopté une solution de startup, mais comme elle utilisait MongoDB et que l’équipe d’exploitation n’avait pas les compétences, on a préféré souscrire un service bien accompagné comme Atlas plutôt que de former l’équipe. On n’utilisait que des firewalls qu’on connaissait, au lieu du firewall Azure peu familier, et on gérait aussi toute une série de contrats. Résultat : moins de recrutements, un interlocuteur unique, et des gains d’efficacité. Une licence de startup coûte 5 à 10 K$ par an, mais le support peut coûter bien plus, par exemple 40 K$. Les startups et l’enterprise, ce sont deux mondes totalement différents
  • J’analyse des données clients de l’ordre du téraoctet avec StarRocks open source et un opérateur k8s, et dans mon environnement j’ai l’impression que Databricks ne m’est quasiment d’aucune utilité
  • J’utilise ClickHouse depuis plusieurs années sans problème. La base inspire confiance et couvre un large éventail de fonctionnalités. La fonction d’external dictionary facilite l’intégration avec d’autres datastores comme Postgres ou Redis
  • Si vous cherchez une alternative open source à Cloudera basée sur des opérateurs Kubernetes, nous développons stackable.tech depuis 5 ans. Le vrai problème, c’est le S3 open source on-premise. Je ne recommande pas MinIO, et à part ça il n’y a presque aucun acteur capable de répondre aux besoins enterprise
  • Le data warehousing est banalisé depuis plusieurs décennies. Il existe un long historique sur les prix et les performances, et les produits SnowBricks n’y répondent pas vraiment. Ce n’est qu’une différence entre vente forcée et vente en douceur
  • Je ne vois pas pourquoi il faudrait acheter une base opérationnelle chez Databricks. Ça ressemble surtout aux efforts de Databricks pour préserver sa valorisation
  • Si Databricks avait simplement eu besoin d’une row DB, ils auraient construit leur propre Postgres. S’ils ont mis autant d’argent sur Neon, c’est le signe qu’ils voulaient quelque chose de spécial chez Neon, comme le “stockage et le compute évolutifs indépendamment”
  • Je serais curieux de savoir ce que vous utilisez pour l’ETL
• J’ai postulé chez neon la semaine dernière, puis l’annonce du rachat est tombée, et ce matin j’ai reçu immédiatement un refus. C’est l’expérience de refus la plus heureuse de ma vie. J’ai failli rejoindre trois entreprises rachetées d’affilée, et maintenant je veux juste de la stabilité. Félicitations à l’équipe neon. J’aime neon et je l’utilise, et j’espère que ce rachat ne changera pas trop les choses
  • J’avais rejoint Kenna Security avant son rachat, puis Cisco l’a acquise un mois plus tard. Une expérience absolument horrible, et je ne retravaillerai jamais ni dans une entreprise dirigée par l’ancienne équipe de Kenna, ni chez Cisco
  • J’ai eu exactement l’expérience inverse. Rejoindre une entreprise au moment d’un rachat a été la période la plus intéressante. Dans mon cas, l’expérience d’intégration post-acquisition a même conduit à ce qu’on vienne régulièrement me débaucher
  • J’étais engineering manager en première année lors d’un rachat, et j’ai aidé à traverser deux vagues de licenciements, à choisir qui garder et à réorganiser les équipes. Le moral était au plus bas et la culture d’entreprise ne collait pas du tout. J’ai fait un gros burn-out, j’ai pris quelques mois de pause, et maintenant je suis redevenu IC, beaucoup plus heureux
  • À mon avis, l’équipe neon sera absorbée dans la technologie Online Tables de Databricks. Ça aurait du sens côté produit
  • Je me demande ce que ça fait d’avoir rejoint neon à l’époque de son ancienne valorisation et de terminer juste sa période de vesting au moment de ce rachat, avec un gros chèque qui tombe soudainement
• Databricks est l’un des logiciels les plus irritants et nuls que j’aie jamais utilisés. Je suis surpris que qui que ce soit l’utilise volontairement
  • Databricks a démarré en 2013, quand Spark n’était pas terrible, et l’entreprise a rendu Spark meilleur et plus rapide. Le produit reste très centré sur Spark, mais je pense qu’un combo Iceberg + DuckDB convient mieux à 95 % des entreprises. C’est moins cher, plus rapide, plus simple à manipuler, et c’est sur cette hypothèse qu’on construit chez Definite notre plateforme data (ETL, BI, Data Lake inclus)
  • Databricks, c’est le Jira de la donnée. Personne n’a envie de l’utiliser, ce n’est pas terrible, et à force de vouloir convenir à tout le monde, chaque fonctionnalité paraît maladroite. Il existe maintenant bien de meilleures alternatives, donc je ne choisirais jamais Databricks de mon plein gré
  • J’ai vraiment du mal à être d’accord. En venant du monde Hadoop, Databricks ressemble à une utopie. C’est stable, rapide, et ça passe très bien à l’échelle sur de gros jeux de données. Mon principal reproche, c’est juste le prix, beaucoup trop élevé
  • J’aimais bien la plateforme Databricks par le passé. En 2020-2021, face à AWS, Azure et Snowflake, il n’y avait pratiquement que Databricks comme alternative raisonnable. Aujourd’hui, entre l’empilement de fonctionnalités, les changements fréquents et les acquisitions, c’est devenu désordonné, et même les noms des fonctionnalités sont confus
  • Il restait donc encore un marché pour les logiciels façon IBM (tout le monde les utilise, donc nous aussi)
  • Franchement, Databricks est un produit vraiment ennuyeux. Quand je repense à la fin des années 2010, Spark-as-a-Service était excellent, à une époque où les entreprises échouaient à faire tourner Spark de façon fiable par elles-mêmes. Même les hyperscalers avaient des offres de première génération assez faibles, et malgré des problèmes comme la compatibilité Jupyter du format de notebooks Databricks, l’instabilité des clusters on-prem était un problème bien plus douloureux, donc on acceptait volontiers de payer la prime. À l’époque, Databricks était aussi une très belle activité à 1 milliard de dollars. Mais on ne devient pas une licorne juste avec du Spark-aaS. AWS EMR arrivait lentement comme concurrent, et Databricks a fini par gonfler son produit à outrance en misant tout sur sa stratégie de croissance, en bombardant le marché de buzzwords autour de data, lake et house. En 2025, le déclin de Databricks est une illustration amère de l’enshittification. Un jour, Larry Ellison finira peut-être par les racheter et les faire disparaître du marché. Je ne comprends pas pourquoi on choisirait Databricks pour un nouveau projet aujourd’hui, mais les entreprises qui l’utilisent depuis plus de 5 ans auront du mal à en sortir. Leur part de marché va probablement reculer, mais ils continueront à gagner de l’argent pendant un moment. C’est le cycle du secteur, et au final l’entropie gagne toujours. Je ne les déteste pas tant que ça : c’est une entreprise qui a quand même écrit une histoire assez respectable
  • Ils insistent énormément sur le serverless, mais il y a trop de limites et de pièges cachés, c’est vraiment exaspérant
  • Je me demande si l’hébergement de Spark a vraiment été une innovation. Et j’ai toujours douté du fait que Spark lui-même ne soit pas trop complexe pour 90 % du traitement de données dans les entreprises établies. Je ne comprends pas pourquoi cette entreprise vaut autant
  • Le site web ne charge même plus du tout si on désactive les cookies, et c’est un énorme signal d’alerte. Une entreprise incapable de faire fonctionner correctement un simple site web n’inspire pas confiance pour construire de bons produits numériques
• Databricks est aussi mauvais qu’Oracle. Je suis convaincu qu’ils vont soit ruiner Neon, soit le rendre hors de prix. Je vais chercher des alternatives à Neon à moyen-long terme
  • La stratégie M&A de Databricks étouffe structurellement les sociétés qu’ils rachètent. Ils ont du mal à faire face au grand bouleversement open source avec Iceberg, DuckDB, etc. Ils essaient d’innover via les acquisitions, mais leur culture d’entreprise fait s’effondrer les sociétés acquises. Je peux être biaisé, venant du big data (ex-Snowflake), mais il me semble clair que l’open source gagne du terrain. Je suis très curieux de voir comment ce changement va évoluer
• Citation de l’article : « L’an dernier, au moment où Neon est passé en GA, 30 % des bases de données créées l’étaient par des agents IA, et en regardant de nouveau récemment, cette part dépassait 80 %. Cela signifie que l’IA a créé quatre fois plus de bases de données que les humains. » Ce chiffre déclenche pas mal d’alarmes. On dirait que Databricks veut habiller Postgres en solution IA. Le monde devient vraiment étrange
  • Je me demande combien de ces bases sont réellement utilisées en production
• Félicitations à l’équipe Neon. J’aime beaucoup ce qu’ils ont construit. Mais honnêtement, je ne perçois pas le lien ni la synergie avec Databricks, et j’espère que Neon restera un produit distinct. Sinon, le marché perdra un fournisseur Postgres clairement identifié
  • Vu leur forte dépendance à Azure, je ne pense pas qu’ils vont disparaître tout de suite. Databricks semble vouloir s’étendre des bases analytiques vers les bases transactionnelles
  • La FAQ dit que l’entreprise continuera à fonctionner de manière indépendante, mais en pratique j’ai l’impression qu’on connaît déjà la suite
• Je me souviens du tout premier post de l’équipe Neon sur HN. Déjà à l’époque, j’avais commenté que l’idée était excellente. Je n’ai pas encore eu besoin de l’utiliser moi-même, mais je pensais que ce serait le cas un jour. Pourtant, quand je vois ce genre de nouvelle de rachat, ça me laisse sceptique. Je crains qu’ils se concentrent désormais davantage sur les propriétaires que sur les utilisateurs. En théorie, les intérêts devraient être alignés, mais dans la pratique c’est rarement le cas
  • Je me souviens moi aussi du premier post de Neon. La séparation stockage-compute m’avait paru novatrice, et j’avais posé des questions sur le Pageserver. Deux ans plus tard, j’ai fini par travailler moi aussi sur un stockage séparé similaire chez Turso database. Encore félicitations à l’équipe Neon
  • Cette acquisition me fait moi aussi hésiter. J’ai du mal à croire que privilégier les utilisateurs de l’IA aligne vraiment les intérêts des développeurs et du produit. J’espère au moins que la technologie liée au cœur de PostgreSQL profitera à la communauté open source
• Félicitations à l’équipe Neon. Excellent produit. Évidemment, avec du financement VC, ce genre d’issue me semble inévitable. J’espère que Nikita et les autres ne se feront pas absorber par Databricks et resteront solides
• C’est une évolution vraiment intéressante. Je pense que la convergence entre OLTP et OLAP va dans la bonne direction. Avec l’OP, j’ai travaillé sur un système HTAP chez SingleStore. Nous essayions de faire de l’OLTP et de l’OLAP dans une base unique (avec une seule copie servant les deux), mais le HTAP n’a pas vraiment marché. Il faut laisser l’OLTP à Postgres, l’OLAP au data warehouse/data lake, puis concevoir efficacement la réplication entre les deux. La réplication synchrone est difficile. Les stockages en colonnes encaissent mal les écritures OLTP. J’ai hâte de voir si Databricks et Neon pourront concrétiser le scénario consistant à “utiliser directement les tables Postgres les plus récentes dans Unity Catalog” (sans passer par Debezium, Kafka, Flink ni Iceberg, Spark assurant lui-même la maintenance de l’état Iceberg)
  • Quand vous dites OP, vous parlez de Nikita Shamgunov, le fondateur de Neon (et auparavant de MemSQL/SingleStore) ?
• Félicitations à l’équipe Neon. Honnêtement, je suis un peu déçu. J’espérais que Neon comblerait le vide laissé par CockroachDB après son passage à la source business. Depuis son rachat par Databricks, Neon me paraît moins attractif. J’ai du mal à faire confiance à une grande entreprise pour gérer une infrastructure critique. Il y a clairement une demande pour un PostgreSQL “moderne”, mais aucune des alternatives que j’ai regardées ne reste vraiment proche de la racine (en termes de prix, de compatibilité, d’ouverture du code source, etc.). Quand je compare les alternatives à Postgres, voici ce que j’examine
  (1) AWS RDS : nous l’utilisions déjà, mais c’était cher, avec des limites de scalabilité et des problèmes opérationnels
  (2) AWS Aurora : ça résout une partie des problèmes opérationnels, mais avec d’autres inconvénients, et des limites proches des autres alternatives Postgres compatibles au niveau du protocole
  (3) CockroachDB : très intéressant, mais avec des soucis de compatibilité de toolchain et de compatibilité profonde, et à l’époque c’était open source
  (4) Neon : encore immature à mes yeux, donc je ne l’ai pas adopté, mais ça me semblait intéressant et potentiellement capable de résoudre beaucoup de problèmes
  (5) Yugabyte : là aussi une technologie intéressante, mais avec divers problèmes de compatibilité
  J’ai aussi envisagé d’héberger Postgres moi-même, mais l’exploitation de postgres sur Kubernetes me semblait trop lourde. Les fonctions maison de réplication ou d’exploitation n’étaient pas encore assez mûres, et au moment des upgrades, devoir décharger puis recharger toutes les données était extrêmement pénible. La montée en charge comme l’automatisation n’étaient pas faciles
  • À propos de la comparaison avec Yugabyte au motif que son moteur de requêtes serait basé sur Postgres, rappel : Neon, lui, est Postgres
  • Je partage mon expérience à court terme : “la meilleure alternative moderne à Postgres, c’est Postgres lui-même (dans 5 ans)”
  • J’aimerais en savoir plus sur ces “mêmes inconvénients” que vous attribuez aux autres alternatives PostgreSQL compatibles au niveau du protocole