La rivalité entre Databricks et Google dans les bases de données s’intensifie après l’acquisition de Neon

Databricks a acquis Neon après un accord d’un milliard de dollars annoncé, faisant entrer la concurrence entre Databricks et Google dans le marché des bases de données opérationnelles. L’accord a été annoncé en mai 2025, puis finalisé. Ses conséquences sont devenues plus visibles lorsque la technologie de Neon a été intégrée à Databricks sous le nom de Lakebase.

Il ne s’agissait pas simplement d’un nouvel achat de base de données. Databricks avait bâti sa position autour de l’analytique, du machine learning et des données stockées pour un traitement à grande échelle. Neon lui a apporté un système compatible PostgreSQL pour les transactions en temps réel que les applications génèrent chaque seconde.

Cette initiative rapproche Databricks de Google Cloud, Amazon Web Services, Microsoft et Snowflake. Chaque entreprise cherche à contrôler la couche de données sous-jacente aux agents IA. Google propose déjà AlloyDB, Cloud SQL, Spanner, BigQuery, Vertex AI et ses outils de développement d’agents.

La question centrale n’est plus de savoir si Databricks peut analyser les données d’entreprise. Elle est de savoir si Databricks peut devenir l’endroit où les applications IA créent, mettent à jour, gouvernent et analysent ces données.

L’accord avec Neon a comblé une lacune critique

Neon a apporté à Databricks une architecture de base de données opérationnelle que sa plateforme lakehouse ne proposait pas auparavant.

Databricks a annoncé son accord pour acquérir Neon le 14 mai 2025. Son communiqué d’acquisition décrivait Neon comme une entreprise de PostgreSQL serverless conçue pour les développeurs et les agents IA.

PostgreSQL est une base de données relationnelle open source utilisée par les applications pour stocker des informations structurées et fréquemment modifiées. Elle prend en charge les requêtes SQL courantes, les transactions, les extensions et un vaste écosystème de développeurs.

Neon a repensé PostgreSQL pour l’infrastructure cloud en séparant le calcul du stockage. Le traitement de la base de données peut évoluer indépendamment, tandis que les informations durables restent dans un stockage partagé. Une charge de travail peut réduire les ressources de calcul inactives, créer des branches isolées et provisionner de nouveaux environnements sans dupliquer une base de données entière.

Ce modèle compte pour les logiciels générés par IA. Une équipe de développement humaine peut créer plusieurs bases de données pour la production, les tests et la préproduction. Un agent de programmation automatisé peut générer de nombreux projets temporaires, branches, tests et instances de base de données au cours de la même période.

Neon a indiqué que les agents IA créaient déjà la plupart des nouvelles bases de données sur son service lorsque la transaction a été annoncée. Le CEO de Databricks, Ali Ghodsi, a ensuite déclaré à Axios que Neon avait signalé que les agents créaient 80 % de ses bases de données.

Cette statistique provenait de Neon plutôt que d’un audit indépendant. Elle expliquait toutefois la logique stratégique. Databricks n’achetait pas la compatibilité PostgreSQL uniquement pour des applications d’entreprise conventionnelles. L’entreprise achetait une infrastructure conçue pour créer des logiciels à la vitesse des machines.

Les fondateurs de Neon poursuivaient cette architecture depuis le lancement de l’entreprise en 2021. L’annonce de l’accord de l’entreprise indiquait que son objectif initial était un service PostgreSQL cloud-native que les développeurs apprécieraient d’utiliser.

Pour Databricks, Neon fournissait trois composants manquants.

Premièrement, Neon apportait le stockage transactionnel. Databricks s’était concentré sur les charges de travail analytiques, où les entreprises traitent de vastes ensembles de données historiques ou en streaming. Les applications opérationnelles nécessitent des lectures et écritures à plus faible latence, avec une gestion fiable des transactions.

Deuxièmement, Neon apportait un modèle de provisionnement orienté développeur. Une base de données peut apparaître comme une ressource applicative plutôt que comme un projet d’infrastructure géré manuellement. Cette différence devient importante lorsque des agents créent des environnements automatiquement.

Troisièmement, Neon apportait un point d’entrée sur le marché PostgreSQL. Les développeurs connaissent déjà les outils, pilotes, extensions et la syntaxe de requête PostgreSQL. Databricks pouvait étendre sa plateforme sans imposer un modèle de programmation totalement inconnu.

L’acquisition prolongeait aussi la stratégie de Databricks consistant à acheter des technologies fondamentales. MosaicML a ajouté des capacités d’entraînement pour l’IA générative. Tabular a apporté une expertise liée à Apache Iceberg et aux formats de données ouverts. Neon a ajouté une base de données opérationnelle.

Ensemble, ces transactions révèlent une ambition plus vaste. Databricks veut contrôler une plus grande partie du parcours allant des données brutes d’entreprise aux applications IA en production.

L’entreprise dépend toujours de l’infrastructure cloud sous-jacente. Databricks fonctionne sur AWS, Microsoft Azure et Google Cloud. Neon ne supprime pas cette dépendance. Il donne à Databricks une couche logicielle supplémentaire pouvant façonner la manière dont les clients utilisent ces clouds.

Cette distinction crée la tension centrale de l’article. Databricks reste partenaire des principaux fournisseurs de cloud tout en concurrençant de plus en plus leurs services de bases de données et d’IA.

Pourquoi la concurrence entre Databricks et Google inclut désormais PostgreSQL

La relation entre Databricks et Google associe un partenariat d’infrastructure à une concurrence directe pour les charges de travail des applications IA.

Databricks et Google Cloud travaillent ensemble depuis des années. Les clients peuvent exécuter Databricks sur Google Cloud, le connecter au stockage cloud et intégrer des charges de travail à des services tels que BigQuery et Vertex AI.

Ce partenariat demeure important sur le plan commercial. Les entreprises remplacent rarement tout leur environnement cloud parce qu’un fournisseur introduit une nouvelle base de données. Elles combinent souvent l’infrastructure, les plateformes de données, les modèles et les applications de plusieurs fournisseurs.

Neon exerce néanmoins une pression concurrentielle, car Google vend ses propres services PostgreSQL. Cloud SQL propose PostgreSQL géré, tandis qu’AlloyDB fournit une base de données compatible PostgreSQL conçue pour les charges de travail cloud exigeantes.

Google a également positionné AlloyDB comme une fondation pour les applications d’IA générative. Sa feuille de route AlloyDB AI comprend la recherche sémantique, l’indexation vectorielle, les requêtes en langage naturel et des connexions aux services de modèles.

Un index vectoriel organise des représentations numériques de textes, d’images ou d’autres contenus. Les applications utilisent ces représentations pour retrouver des informations liées à la demande d’un utilisateur.

L’avantage de Google provient de l’intégration verticale. Un client peut combiner AlloyDB avec les modèles Gemini, Vertex AI, les contrôles d’identité, le réseau, l’observabilité et les outils de développement d’agents de Google. Un seul fournisseur exploite l’essentiel de la pile.

Databricks propose une approche différente. L’entreprise se présente comme une couche de données et d’IA multi-cloud capable de fonctionner à travers les fournisseurs d’infrastructure. Lakebase étend cette proposition à PostgreSQL opérationnel.

Cela crée deux voies concurrentes pour les acheteurs d’entreprise.

La voie de Google commence par le cloud. Le client utilise l’infrastructure Google, les bases de données Google, les modèles Google et les services de gestion Google. La profondeur de l’intégration devient l’attraction principale.

La voie de Databricks commence par la plateforme de données. Le client utilise des informations gouvernées via Databricks, choisit parmi des fournisseurs de cloud et de modèles, et construit des applications à côté des charges de travail analytiques existantes.

Aucune de ces approches n’élimine la complexité. Les clients de Google doivent décider dans quelle mesure ils souhaitent coupler étroitement leurs applications à un seul cloud. Les clients de Databricks doivent évaluer si son abstraction inter-cloud apporte une cohérence opérationnelle suffisante.

L’acquisition de Neon augmente les enjeux, car les bases de données applicatives deviennent souvent des engagements architecturaux durables. Changer de point de terminaison de modèle peut être gérable. Migrer une base de données transactionnelle avec des années de dépendances applicatives est considérablement plus difficile.

La compatibilité PostgreSQL réduit une partie des frictions de migration. Elle ne garantit pas la portabilité. Les services gérés ajoutent autour de la base de données centrale des mécanismes propriétaires d’authentification, de réseau, de surveillance, de branchement, de réplication et d’intégration IA.

Google peut soutenir qu’AlloyDB offre une intégration mature avec ses contrôles cloud et ses services Gemini. Databricks peut soutenir que Lakebase relie les données opérationnelles à l’analytique, à la gouvernance et à l’IA au sein de sa plateforme.

La différence devient concrète dans une application IA de support client. L’application peut stocker les comptes, l’état des conversations, les autorisations et l’état des flux de travail dans PostgreSQL. Elle peut aussi analyser les interactions historiques et récupérer des documents pertinents pour un agent.

Avec Google, l’application peut associer AlloyDB, Vertex AI et BigQuery. Avec Databricks, Lakebase pourrait gérer les transactions tandis que le lakehouse prendrait en charge l’analytique, l’évaluation des modèles et la récupération gouvernée.

L’acheteur choisit davantage que les performances d’une base de données. Cette décision influe sur l’emplacement de l’état applicatif, la façon dont les agents reçoivent leur contexte et la plateforme qui gouverne les accès.

C’est pourquoi le mot-clé principal dépasse le cadre d’une seule acquisition. La concurrence entre Databricks et Google reflète une lutte pour le point de contrôle sous-jacent aux applications IA d’entreprise.

Databricks n’a pas besoin de remplacer l’infrastructure Google Cloud pour exercer une pression. Il lui suffit que les clients considèrent Databricks comme leur principal plan de contrôle des données et de l’IA.

Les agents IA changent ce qu’une base de données doit gérer

La véritable valeur stratégique de Neon réside dans le provisionnement, le branchement et la mise à l’échelle des bases de données pour des flux de travail logiciels automatisés.

Les opérations de base de données traditionnelles supposent que les humains prennent la plupart des décisions d’infrastructure. Un ingénieur demande une base de données, configure les accès, met en place des sauvegardes et crée des environnements de développement.

Les agents de programmation IA compressent ce cycle. Ils peuvent générer une application, exécuter des tests, réviser des schémas et déployer des environnements de prévisualisation avec une intervention humaine limitée. La couche de base de données doit répondre sans devenir un goulot d’étranglement administratif.

Le provisionnement serverless aide, car la capacité n’a pas besoin d’être attribuée via un long processus manuel. Le calcul peut démarrer lorsqu’une charge de travail arrive et diminuer lorsque l’activité s’arrête.

Le branchement est tout aussi important. Une branche de base de données offre à un développeur ou à un agent un environnement isolé dérivé d’un état existant. Les changements peuvent être testés sans modifier les enregistrements de production.

Prenons un agent chargé d’ajouter la gestion des abonnements à une application interne. Il pourrait modifier un schéma, créer des comptes de test, exécuter des scripts de migration et valider des requêtes.

Exécuter ces étapes sur une base de données de production serait risqué. Créer une copie conventionnelle pour chaque tentative consommerait du temps et du stockage. Un flux de travail fondé sur les branches offre une séparation plus claire.

Cette architecture prend également en charge les applications de prévisualisation. Chaque modification de code proposée peut recevoir son propre déploiement applicatif et l’état de base de données associé. Les réviseurs peuvent examiner un logiciel fonctionnel avant que les changements n’atteignent la production.

Ces modèles expliquent pourquoi Databricks voulait davantage qu’un hébergement PostgreSQL générique. Neon avait conçu son service autour de la création rapide, du calcul indépendant et du branchement de bases de données.

Lakebase transpose cette conception dans Databricks. Il associe une base de données opérationnelle compatible PostgreSQL à une plateforme déjà utilisée pour l’ingénierie des données, la gouvernance, l’analytique et le machine learning.

L’avantage potentiel est un chemin plus court entre l’état en temps réel d’une application et son contexte analytique. Un agent pourrait utiliser les enregistrements transactionnels actuels tout en s’appuyant sur des informations gouvernées provenant d’ensembles de données d’entreprise plus larges.

Databricks appelle sa couche de gouvernance Unity Catalog. Dans ce contexte, la gouvernance couvre la découverte, les autorisations, la traçabilité et les contrôles de politique applicables aux données et aux actifs d’IA.

Un catalogue unifié ne résout pas automatiquement la sécurité des applications. Les bases de données opérationnelles ont leurs propres utilisateurs, règles de connexion, frontières transactionnelles et modes de défaillance. Néanmoins, l’intégration d’une identité et de politiques partagées peut réduire l’administration redondante.

Google poursuit un objectif similaire avec une architecture différente. AlloyDB prend en charge les charges de travail PostgreSQL, tandis que Google relie les bases de données à Gemini, Vertex AI et aux frameworks d’agents.

La documentation publique de Google décrit AlloyDB AI comme prenant en charge la recherche vectorielle, l’interaction en langage naturel et les appels à plusieurs fournisseurs de modèles. Cette étendue affaiblit toute affirmation selon laquelle Neon offrirait à Databricks une catégorie de base de données IA unique.

Neon aide plutôt Databricks à rivaliser sur la conception des workflows. L’entreprise peut placer la création de bases de données aux côtés des notebooks, des pipelines de données, des applications, des endpoints de modèles et des enregistrements d’entreprise gouvernés.

Le mécanisme compte davantage que le titre de l’acquisition. Les agents IA augmentent le nombre d’actions d’infrastructure réalisées par développeur. Les bases de données doivent devenir des ressources programmables pouvant apparaître, se ramifier et être retirées via des workflows automatisés.

Un effet de gravité des données entre également en jeu. Lorsqu’une application stocke son état actif sur la même plateforme que celle utilisée pour l’analyse et l’IA, déplacer l’une ou l’autre charge de travail devient plus difficile.

Databricks gagne l’occasion de se développer au sein de ses comptes existants. Un client utilisant la plateforme pour l’analytique peut adopter Lakebase pour une nouvelle application IA. Cette décision peut accroître la consommation de stockage, de calcul, de gouvernance et de services de modèles.

Google bénéficie de l’opportunité inverse. Un client déjà engagé dans Google Cloud peut développer avec AlloyDB et Vertex AI sans ajouter un autre plan de contrôle de plateforme.

La concurrence entre databricks et google se concentre donc sur la commodité pour les développeurs et le contrôle d’entreprise. Les deux entreprises veulent faire de leur plateforme l’emplacement par défaut où une application IA rencontre des données métier fiables.

La base de données gagnante ne sera pas choisie sur la seule base du branding des agents. Elle devra assurer des transactions prévisibles, la récupération, l’observabilité, la sécurité réseau, la disponibilité régionale et des coûts maîtrisables sous de vraies charges de travail.

L’acquisition n’élimine pas le risque opérationnel

Databricks doit encore prouver que l’architecture conviviale pour les développeurs de Neon peut répondre aux exigences de production des entreprises à grande échelle.

L’acquisition a apporté de la technologie et des talents d’ingénierie. Elle n’a pas instantanément donné à Databricks des décennies de crédibilité opérationnelle dans les bases de données.

Les plateformes analytiques et les systèmes transactionnels échouent différemment. Une requête analytique peut parfois être relancée après un délai. Une transaction échouée peut interrompre un paiement, dupliquer une action ou laisser l’état de l’application incohérent.

Les acheteurs d’entreprise examineront les objectifs de récupération, la réplication, le comportement de maintenance, la gestion des connexions, la couverture régionale et l’isolation des charges de travail. Ils testeront également les performances lors de pics soudains créés par les agents.

La séparation du calcul et du stockage offre de la flexibilité, mais introduit des compromis. Une base de données doit déplacer efficacement les informations entre le stockage persistant et le calcul actif. Les démarrages à froid, le comportement du cache et les chemins réseau peuvent affecter la latence.

La ramification exige également des contrôles clairs. Les agents ne doivent pas obtenir un accès illimité aux enregistrements de production simplement parce qu’ils peuvent créer un environnement de base de données isolé.

Les organisations auront besoin de politiques pour masquer les informations sensibles, limiter la création de branches, faire expirer les ressources temporaires et auditer les modifications automatisées. Le nombre d’environnements peut devenir un problème de gouvernance.

La question de l’open source ajoute une autre incertitude. Neon a construit son identité autour de PostgreSQL et de technologies publiquement disponibles. Son acquisition par une grande plateforme peut susciter des inquiétudes quant à la compatibilité future ou à l’orientation du produit.

Databricks possède une histoire ancrée dans des projets open source, notamment Apache Spark et Delta Lake. Ce parcours renforce sa crédibilité, mais les clients jugeront les actes plutôt que l’histoire.

Ils devraient surveiller si le développement principal de Neon reste accessible et si les outils PostgreSQL standard continuent de fonctionner sans modification importante. Les intégrations propriétaires peuvent ajouter de la valeur tout en augmentant les coûts de changement.

Google fait face à la même question de confiance. AlloyDB est compatible avec PostgreSQL plutôt qu’une distribution se comportant de manière identique dans chaque détail. Ses fonctionnalités les plus puissantes dépendent de l’environnement géré de Google.

Les affirmations de portabilité des deux côtés méritent des tests rigoureux. La compatibilité SQL ne couvre pas les outils opérationnels, les systèmes d’identité, les sauvegardes, l’observabilité ou les extensions spécifiques à l’IA.

La pression concurrentielle va également au-delà de Google. Snowflake a acquis le spécialiste PostgreSQL Crunchy Data peu après que Databricks a annoncé la transaction Neon.

Un document réglementaire de Snowflake indique que l’entreprise a finalisé cette acquisition en juin 2025. Le calendrier a montré que PostgreSQL opérationnel était devenu stratégiquement important pour les plateformes de données.

La réponse de Snowflake empêche Databricks de définir seul le marché. L’entreprise peut associer l’expertise de Crunchy Data à ses propres services d’analytique, d’applications et d’IA.

AWS demeure une autre force majeure avec Amazon Aurora et son portefeuille plus large de bases de données. Microsoft peut combiner les bases de données Azure, Fabric, les services Databricks et sa relation avec OpenAI.

Ce marché encombré est utile aux acheteurs, car il encourage un développement plus rapide. Il rend aussi les comparaisons de produits plus difficiles. Chaque fournisseur présente sa base de données comme prête pour les agents IA.

Les acheteurs ont besoin de preuves liées à de vraies charges de travail. Une évaluation utile devrait inclure la latence transactionnelle, des tests de récupération, le temps de création des branches, les limites de connexion, l’effort administratif et le comportement face à une demande variable.

Les équipes devraient également tester les mouvements de données. Une application peut avoir besoin d’enregistrements opérationnels pour l’analytique, l’évaluation de modèles ou la récupération d’informations. L’architecture doit montrer à quelle vitesse ces enregistrements deviennent disponibles et comment les politiques de gouvernance les accompagnent.

Les affirmations des fournisseurs concernant l’adoption des agents exigent une prudence similaire. Une base de données créée par un outil automatisé ne prend pas nécessairement en charge une application de production utile.

Les métriques importantes sont une croissance soutenue des charges de travail, le nombre de bases de données de production actives, la rétention, la fiabilité et l’expansion chez les clients. Databricks n’a pas publiquement fourni suffisamment de détails pour trancher ces questions.

Il existe également un risque d’intégration stratégique. Les produits acquis peuvent perdre de leur élan lorsque les équipes passent des mois à adapter les systèmes d’authentification, de facturation, de support et de gouvernance.

Neon a continué de publier des mises à jour produit après avoir rejoint Databricks, ce qui suggère un développement actif. Toutefois, la continuité des publications ne prouve pas que chaque client Databricks peut adopter Lakebase sans compromis architecturaux.

Une analyse indépendante a décrit l’acquisition comme une étape rapprochant Databricks des hyperscalers. Une évaluation des bases de données a noté que les capacités PostgreSQL étendaient Databricks au-delà de sa concurrence traditionnelle dans la gestion des données.

Cette expansion est stratégiquement attrayante, mais elle relève les attentes. Databricks doit désormais concurrencer des fournisseurs qui exploitent depuis de nombreuses années des bases de données critiques pour l’activité.

L’acquisition a fait de Databricks un participant crédible à cette compétition. Les preuves en production détermineront s’il devient un leader durable des bases de données.

Trois signaux montreront qui gagne du terrain

La disponibilité du produit, l’adoption en production et l’intégration concurrentielle détermineront si Neon modifie le marché.

Le premier signal est l’adoption de Lakebase après sa disponibilité générale. L’intérêt pendant la phase de préversion peut refléter l’expérimentation, tandis que l’usage en production exige des examens de sécurité, des tests opérationnels et un engagement organisationnel.

Les clients devraient rechercher des déploiements nommés prenant en charge des applications orientées client. Les cas les plus solides incluront des caractéristiques de charge de travail mesurables, des exigences de récupération et une intégration avec la gouvernance Databricks.

Une expansion répétée au sein des comptes Databricks existants renforcerait la stratégie de l’entreprise. Elle montrerait que les clients analytiques voient un intérêt à ajouter des charges de travail opérationnelles sur la même plateforme.

Une adoption limitée affaiblirait la thèse. Elle suggérerait que les entreprises préfèrent des services de bases de données établis, même lorsqu’elles utilisent Databricks pour l’analytique et l’IA.

Le deuxième signal est la réponse de Google via AlloyDB et sa plateforme d’agents. Google dispose déjà d’un vaste portefeuille de bases de données, sa réponse n’a donc pas besoin de mentionner Databricks directement.

Les indicateurs significatifs sont des liens plus étroits entre AlloyDB, Gemini, les outils d’agents, BigQuery et les services de gouvernance. Google peut faire de l’intégration verticale sa réponse la plus forte à Databricks.

Ses fonctionnalités IA pour PostgreSQL couvrent désormais la récupération vectorielle, les requêtes en langage naturel, les connexions aux modèles et les workflows orientés agents. Une intégration continue renforcerait la position de Google auprès des clients déjà engagés dans son cloud.

Databricks peut répondre par une cohérence multi-cloud. Si Lakebase se comporte de manière similaire sur AWS, Azure et Google Cloud, les clients obtiennent une alternative à une architecture d’application spécifique à un fournisseur.

Cette affirmation nécessite une vérification opérationnelle. Les dates de disponibilité, la couverture régionale, les fonctionnalités réseau et les options de reprise après sinistre peuvent différer selon les clouds.

Le troisième signal est la manière dont Snowflake et les autres fournisseurs commercialisent PostgreSQL. L’acquisition de Crunchy Data par Snowflake a confirmé que Databricks n’était pas seul à considérer les bases de données opérationnelles comme une couche manquante.

Il faudra observer si Snowflake Postgres devient un service de production étroitement connecté à sa plateforme de données. Une forte adoption répartirait la demande des entreprises et affaiblirait tout récit simpliste à deux entreprises.

AWS peut exercer une pression sur tous les participants grâce à Aurora, Bedrock et sa base de développeurs établie. Microsoft peut combiner les services de bases de données Azure avec Fabric et Azure Databricks.

La concurrence se déroulera donc selon plusieurs dimensions. La fiabilité des bases de données reste fondamentale, mais la gouvernance de plateforme, le choix des modèles, le workflow développeur et la portabilité cloud influencent désormais le même achat.

Pour les développeurs, le bénéfice immédiat est un plus grand choix. Une équipe peut comparer des offres PostgreSQL intégrées sans abandonner SQL, les bibliothèques et les outils qu’elle connaît.

Pour les acheteurs d’entreprise, la décision a des conséquences plus durables. La base de données opérationnelle devient souvent le système d’enregistrement d’une application. Sa plateforme environnante peut façonner la sécurité, l’analytique et le développement IA pendant des années.

Pour les équipes produit IA, la ramification des bases de données mérite une attention particulière. Les agents qui modifient des logiciels ont besoin d’environnements de données isolés, d’identifiants contrôlés et d’un nettoyage automatisé. Une base de données conçue pour un provisionnement au rythme humain peut ralentir l’ensemble du workflow.

La rivalité entre databricks et google ne sera pas tranchée par un seul benchmark ou une seule acquisition. Elle se jouera au fil de décisions de production répétées sur l’endroit où les agents stockent l’état et accèdent aux informations gouvernées.

La transaction Neon est importante parce qu’elle a changé le rôle de Databricks. L’entreprise n’offre plus seulement l’environnement analytique à côté d’une base de données applicative. Elle veut désormais fournir les deux.

Google conserve d’importants avantages en matière de portée d’infrastructure et de services cloud intégrés. Databricks occupe une position forte au sein des équipes de données d’entreprise et peut opérer sur les plus grands clouds.

Cela crée un conflit productif. Google veut que la plateforme cloud organise la stack IA. Databricks veut que la plateforme de données devienne cette couche organisatrice.

Les équipes évaluant l’une ou l’autre voie devraient commencer par une application réelle plutôt que par une liste de fonctionnalités. Testez le comportement transactionnel, l’isolation des branches, la récupération, la gouvernance et l’intégration des modèles sous la demande attendue.

Demandez ensuite qui contrôle le contexte le plus important. Si la réponse est le fournisseur de cloud, la voie intégrée de Google devient attrayante. Si la réponse est la plateforme de données, Databricks gagne en influence.

L’acquisition a transformé ce choix architectural en une décision d’achat immédiate. Surveillez les déploiements de Lakebase en production, une intégration plus poussée d’AlloyDB et le déploiement PostgreSQL de Snowflake. Ces signaux montreront si Databricks a bâti une activité de bases de données durable ou s’il s’est simplement lancé dans une course déjà très encombrée.