La rivalidad entre Databricks y Google en bases de datos se intensifica tras la adquisición de Neon

Databricks adquirió Neon tras un acuerdo reportado de miles de millones de dólares, impulsando la competencia entre Databricks y Google hacia el mercado de las bases de datos operativas. El acuerdo se anunció en mayo de 2025 y posteriormente se completó. Sus consecuencias quedaron más claras cuando la tecnología de Neon surgió dentro de Databricks como Lakebase.

No fue simplemente otra compra de una base de datos. Databricks había construido su posición en torno a la analítica, el aprendizaje automático y los datos almacenados para procesamiento a gran escala. Neon le proporcionó un sistema compatible con PostgreSQL para las transacciones en tiempo real que las aplicaciones generan cada segundo.

Este movimiento acerca a Databricks a Google Cloud, Amazon Web Services, Microsoft y Snowflake. Cada empresa quiere controlar la capa de datos que sustenta a los agentes de IA. Google ya ofrece AlloyDB, Cloud SQL, Spanner, BigQuery, Vertex AI y sus herramientas de desarrollo de agentes.

La cuestión central ya no es si Databricks puede analizar datos empresariales. Es si Databricks puede convertirse en el lugar donde las aplicaciones de IA crean, actualizan, gobiernan y analizan esos datos.

El acuerdo con Neon cubrió una brecha crítica

Neon proporcionó a Databricks una arquitectura de base de datos operativa que su plataforma lakehouse no ofrecía anteriormente.

Databricks anunció su acuerdo para adquirir Neon el 14 de mayo de 2025. Su declaración de adquisición describía a Neon como una empresa de PostgreSQL sin servidor creada para desarrolladores y agentes de IA.

PostgreSQL es una base de datos relacional de código abierto que las aplicaciones utilizan para almacenar información estructurada y que cambia con frecuencia. Admite consultas SQL conocidas, transacciones, extensiones y un amplio ecosistema de desarrolladores.

Neon rediseñó PostgreSQL para la infraestructura en la nube al separar el cómputo del almacenamiento. El procesamiento de la base de datos puede escalar de forma independiente mientras la información persistente permanece en almacenamiento compartido. Una carga de trabajo puede reducir el cómputo inactivo, crear ramas aisladas y aprovisionar nuevos entornos sin duplicar una base de datos completa.

Este modelo importa para el software generado por IA. Un equipo humano de desarrollo podría crear varias bases de datos para producción, pruebas y preproducción. Un agente de programación automatizado puede generar muchos proyectos temporales, ramas, pruebas e instancias de bases de datos durante el mismo período.

Neon afirmó que, cuando se anunció la transacción, los agentes de IA ya creaban la mayoría de las nuevas bases de datos de su servicio. El CEO de Databricks, Ali Ghodsi, dijo posteriormente a Axios que Neon informó que los agentes creaban el 80 por ciento de sus bases de datos.

La estadística procedía de Neon, no de una auditoría independiente. Sin embargo, explicaba la lógica estratégica. Databricks no estaba comprando compatibilidad con PostgreSQL únicamente para aplicaciones empresariales convencionales. Estaba comprando infraestructura diseñada para crear software a velocidad de máquina.

Los fundadores de Neon habían desarrollado esta arquitectura desde el lanzamiento de la empresa en 2021. El anuncio del acuerdo de la empresa indicaba que su objetivo original era crear un servicio PostgreSQL nativo de la nube que los desarrolladores disfrutaran utilizar.

Para Databricks, Neon aportó tres componentes que faltaban.

En primer lugar, aportó almacenamiento transaccional. Databricks se había centrado en cargas de trabajo analíticas, donde las empresas procesan grandes colecciones de datos históricos o en streaming. Las aplicaciones operativas necesitan lecturas y escrituras de menor latencia con una gestión fiable de transacciones.

En segundo lugar, Neon aportó un modelo de aprovisionamiento orientado a desarrolladores. Una base de datos puede aparecer como un recurso de aplicación en lugar de un proyecto de infraestructura gestionado manualmente. Esa diferencia cobra importancia cuando los agentes crean entornos automáticamente.

En tercer lugar, Neon aportó un punto de entrada al mercado de PostgreSQL. Los desarrolladores ya comprenden las herramientas, los controladores, las extensiones y la sintaxis de consultas de PostgreSQL. Databricks podía ampliar su plataforma sin exigir un modelo de programación completamente desconocido.

La adquisición también continuó el patrón de Databricks de comprar tecnologías fundamentales. MosaicML añadió capacidades de entrenamiento de IA generativa. Tabular aportó conocimientos relacionados con Apache Iceberg y los formatos de datos abiertos. Neon añadió una base de datos operativa.

En conjunto, estas transacciones revelan una ambición más amplia. Databricks quiere controlar una mayor parte del camino que va desde los datos empresariales en bruto hasta las aplicaciones de IA en producción.

La empresa sigue dependiendo de la infraestructura subyacente en la nube. Databricks funciona en AWS, Microsoft Azure y Google Cloud. Neon no elimina esa dependencia. Le proporciona a Databricks otra capa de software que puede moldear cómo los clientes utilizan esas nubes.

Esta distinción crea la tensión central del artículo. Databricks sigue siendo socio de los grandes proveedores de nube mientras compite cada vez más con sus servicios de bases de datos e IA.

Por qué la competencia entre Databricks y Google ahora incluye PostgreSQL

La relación entre Databricks y Google combina una alianza de infraestructura con competencia directa por las cargas de trabajo de aplicaciones de IA.

Databricks y Google Cloud han trabajado juntos durante años. Los clientes pueden ejecutar Databricks en Google Cloud, conectarlo con almacenamiento en la nube e integrar cargas de trabajo con servicios como BigQuery y Vertex AI.

Esta alianza sigue siendo importante desde el punto de vista comercial. Rara vez las empresas sustituyen todo un entorno de nube porque un proveedor introduce una nueva base de datos. A menudo combinan infraestructura, plataformas de datos, modelos y aplicaciones de varios proveedores.

Neon sigue generando presión competitiva porque Google vende sus propios servicios de PostgreSQL. Cloud SQL ofrece PostgreSQL gestionado, mientras que AlloyDB proporciona una base de datos compatible con PostgreSQL diseñada para cargas de trabajo exigentes en la nube.

Google también ha posicionado AlloyDB como una base para aplicaciones de IA generativa. Su hoja de ruta de AlloyDB AI incluye búsqueda semántica, indexación vectorial, consultas en lenguaje natural y conexiones con servicios de modelos.

Un índice vectorial organiza representaciones numéricas de texto, imágenes u otro contenido. Las aplicaciones utilizan esas representaciones para recuperar información relacionada con la solicitud de un usuario.

La ventaja de Google proviene de la integración vertical. Un cliente puede combinar AlloyDB con modelos Gemini, Vertex AI, controles de identidad, redes, observabilidad y las herramientas de desarrollo de agentes de Google. Un solo proveedor opera la mayor parte de la pila.

Databricks ofrece una propuesta diferente. Se presenta como una capa de datos e IA multinube que puede funcionar entre proveedores de infraestructura. Lakebase extiende esa propuesta al PostgreSQL operativo.

Esto crea dos rutas competidoras para los compradores empresariales.

La ruta de Google comienza con la nube. El cliente utiliza infraestructura de Google, bases de datos de Google, modelos de Google y servicios de gestión de Google. La profundidad de integración se convierte en el principal atractivo.

La ruta de Databricks comienza con la plataforma de datos. El cliente utiliza información gobernada mediante Databricks, elige entre proveedores de nube y modelos, y crea aplicaciones junto a las cargas de trabajo analíticas existentes.

Ninguno de los dos enfoques elimina la complejidad. Los clientes de Google deben decidir hasta qué punto quieren acoplar sus aplicaciones a una sola nube. Los clientes de Databricks deben evaluar si su abstracción entre nubes ofrece suficiente coherencia operativa.

La adquisición de Neon eleva la importancia de esta cuestión porque las bases de datos de aplicaciones suelen convertirse en compromisos arquitectónicos duraderos. Mover un endpoint de modelo puede ser manejable. Migrar una base de datos transaccional con años de dependencias de aplicaciones es considerablemente más difícil.

La compatibilidad con PostgreSQL reduce parte de la fricción de migración. No garantiza la portabilidad. Los servicios gestionados introducen autenticación, redes, monitorización, ramificación, replicación e integraciones de IA propietarias alrededor de la base de datos central.

Google puede sostener que AlloyDB ofrece una integración madura con sus controles de nube y servicios Gemini. Databricks puede sostener que Lakebase conecta los datos operativos con la analítica, la gobernanza y la IA dentro de su plataforma.

La diferencia se vuelve concreta en una aplicación de atención al cliente con IA. La aplicación podría almacenar cuentas, estado de conversaciones, permisos y estado de flujos de trabajo en PostgreSQL. También podría analizar interacciones históricas y recuperar documentos relevantes para un agente.

Con Google, la aplicación podría combinar AlloyDB, Vertex AI y BigQuery. Con Databricks, Lakebase podría gestionar las transacciones mientras el lakehouse respalda la analítica, la evaluación de modelos y la recuperación gobernada.

El comprador está eligiendo algo más que el rendimiento de una base de datos. La decisión afecta dónde reside el estado de la aplicación, cómo los agentes reciben contexto y qué plataforma gobierna el acceso.

Por eso la palabra clave principal abarca más que una sola adquisición. La competencia entre Databricks y Google refleja una lucha por el punto de control que sustenta las aplicaciones empresariales de IA.

Databricks no necesita desplazar la infraestructura de Google Cloud para generar presión. Solo necesita que los clientes consideren a Databricks como su principal plano de control de datos e IA.

Los agentes de IA cambian lo que debe gestionar una base de datos

El verdadero valor estratégico de Neon reside en aprovisionar, ramificar y escalar bases de datos para flujos de trabajo de software automatizados.

Las operaciones tradicionales de bases de datos suponen que las personas toman la mayoría de las decisiones de infraestructura. Un ingeniero solicita una base de datos, configura el acceso, establece copias de seguridad y crea entornos de desarrollo.

Los agentes de programación de IA comprimen ese ciclo. Pueden generar una aplicación, ejecutar pruebas, revisar esquemas y desplegar entornos de vista previa con una intervención humana limitada. La capa de base de datos debe responder sin convertirse en un cuello de botella administrativo.

El aprovisionamiento sin servidor ayuda porque no es necesario asignar capacidad mediante un proceso manual prolongado. El cómputo puede iniciarse cuando llega una carga de trabajo y reducirse cuando cesa la actividad.

La ramificación es igual de importante. Una rama de base de datos proporciona a un desarrollador o agente un entorno aislado derivado de un estado existente. Los cambios se pueden probar sin alterar los registros de producción.

Pensemos en un agente al que se le pide añadir gestión de suscripciones a una aplicación interna. Podría modificar un esquema, crear cuentas de prueba, ejecutar scripts de migración y validar consultas.

Ejecutar estos pasos contra una base de datos de producción sería inseguro. Crear una copia convencional para cada intento consumiría tiempo y almacenamiento. Un flujo de trabajo basado en ramas ofrece un límite más limpio.

La arquitectura también admite aplicaciones de vista previa. Cada cambio de código propuesto puede recibir su propio despliegue de aplicación y el estado de base de datos relacionado. Los revisores pueden inspeccionar software funcional antes de que los cambios lleguen a producción.

Estos patrones explican por qué Databricks quería algo más que alojamiento genérico de PostgreSQL. Neon había diseñado su servicio en torno a la creación rápida, el cómputo independiente y la ramificación de bases de datos.

Lakebase lleva ese diseño a Databricks. Conecta una base de datos operativa compatible con PostgreSQL con una plataforma ya utilizada para ingeniería de datos, gobernanza, analítica y aprendizaje automático.

El beneficio potencial es un camino más corto entre el estado en tiempo real de una aplicación y su contexto analítico. Un agente podría utilizar registros transaccionales actuales mientras recurre a información gobernada procedente de conjuntos de datos empresariales más amplios.

Databricks denomina Unity Catalog a su capa de gobernanza. La gobernanza, en este contexto, abarca descubrimiento, permisos, linaje y controles de políticas para datos y activos de IA.

Un catálogo unificado no resuelve automáticamente la seguridad de las aplicaciones. Las bases de datos operativas tienen sus propios usuarios, reglas de conexión, límites transaccionales y modos de fallo. Aun así, una identidad compartida y la integración de políticas pueden reducir la administración duplicada.

Google persigue un destino similar mediante una arquitectura distinta. AlloyDB admite cargas de trabajo de PostgreSQL, mientras Google conecta bases de datos con Gemini, Vertex AI y frameworks de agentes.

La documentación pública de Google describe AlloyDB AI como compatible con búsqueda vectorial, interacción en lenguaje natural y llamadas a múltiples proveedores de modelos. Esa amplitud debilita cualquier afirmación de que Neon otorga a Databricks una categoría de base de datos de IA única.

En cambio, Neon ayuda a Databricks a competir en el diseño de flujos de trabajo. La empresa puede situar la creación de bases de datos junto a notebooks, pipelines de datos, aplicaciones, endpoints de modelos y registros empresariales gobernados.

El mecanismo es más importante que el titular de la adquisición. Los agentes de IA aumentan la cantidad de acciones de infraestructura realizadas por desarrollador. Las bases de datos deben convertirse en recursos programables capaces de aparecer, ramificarse y retirarse mediante flujos de trabajo automatizados.

También existe un efecto de gravedad de datos. Una vez que una aplicación almacena estado activo en la misma plataforma utilizada para análisis e IA, resulta más difícil mover cualquiera de las dos cargas de trabajo.

Databricks obtiene una oportunidad para expandirse dentro de las cuentas existentes. Un cliente que utiliza la plataforma para analítica puede adoptar Lakebase para una nueva aplicación de IA. Esa decisión puede aumentar el consumo de almacenamiento, cómputo, gobernanza y servicios de modelos.

Google enfrenta la oportunidad inversa. Un cliente ya comprometido con Google Cloud puede desarrollar con AlloyDB y Vertex AI sin añadir otro plano de control de plataforma.

Por tanto, la competencia entre databricks y google se centra en la comodidad para desarrolladores y el control empresarial. Ambas empresas quieren que su plataforma sea el lugar predeterminado donde una aplicación de IA se encuentra con datos empresariales confiables.

La base de datos ganadora no se elegirá únicamente por la marca de agentes. Debe ofrecer transacciones predecibles, recuperación, observabilidad, seguridad de red, disponibilidad regional y costes gestionables con cargas de trabajo reales.

La adquisición no elimina el riesgo operativo

Databricks aún debe demostrar que la arquitectura amigable para desarrolladores de Neon puede satisfacer los requisitos de producción empresariales a escala.

La adquisición aportó tecnología y talento de ingeniería. No otorgó instantáneamente a Databricks décadas de credibilidad en operaciones de bases de datos.

Las plataformas analíticas y los sistemas transaccionales fallan de manera diferente. Una consulta analítica a veces puede reintentarse tras una demora. Una transacción fallida puede interrumpir un pago, duplicar una acción o dejar el estado de la aplicación inconsistente.

Los compradores empresariales examinarán los objetivos de recuperación, la replicación, el comportamiento de mantenimiento, la gestión de conexiones, la cobertura regional y el aislamiento de cargas de trabajo. También probarán el rendimiento durante picos repentinos generados por agentes.

La separación entre cómputo y almacenamiento ofrece flexibilidad, pero introduce compromisos. Una base de datos debe mover información de forma eficiente entre el almacenamiento persistente y el cómputo activo. Los arranques en frío, el comportamiento de la caché y las rutas de red pueden afectar la latencia.

La ramificación también requiere controles claros. Los agentes no deberían obtener acceso sin restricciones a registros de producción simplemente porque pueden crear un entorno de base de datos aislado.

Las organizaciones necesitarán políticas para enmascarar información sensible, limitar la creación de ramas, expirar recursos temporales y auditar cambios automatizados. La cantidad de entornos puede convertirse en un problema de gobernanza.

La cuestión del código abierto añade otra incertidumbre. Neon construyó su identidad en torno a PostgreSQL y tecnología disponible públicamente. La adquisición por una gran plataforma puede generar preocupación sobre la compatibilidad futura o la dirección del producto.

Databricks tiene una historia vinculada a proyectos de código abierto, incluidos Apache Spark y Delta Lake. Ese antecedente respalda su credibilidad, pero los clientes juzgarán el comportamiento antes que la historia.

Deberían observar si el desarrollo central de Neon sigue siendo accesible y si las herramientas estándar de PostgreSQL continúan funcionando sin modificaciones significativas. Las integraciones propietarias pueden aportar valor al tiempo que aumentan los costes de cambio.

Google enfrenta la misma cuestión de confianza. AlloyDB es compatible con PostgreSQL, en lugar de ser una distribución que se comporte de manera idéntica en cada detalle. Sus funciones más potentes dependen del entorno gestionado de Google.

Las afirmaciones de portabilidad de ambos lados merecen pruebas cuidadosas. La compatibilidad con SQL no cubre las herramientas operativas, los sistemas de identidad, las copias de seguridad, la observabilidad ni las extensiones específicas de IA.

La presión competitiva también se extiende más allá de Google. Snowflake adquirió al especialista en PostgreSQL Crunchy Data poco después de que Databricks anunciara la transacción con Neon.

Una presentación regulatoria de Snowflake indica que la empresa completó esa adquisición en junio de 2025. El momento mostró que PostgreSQL operativo se había vuelto estratégicamente importante en todas las plataformas de datos.

La respuesta de Snowflake impide que Databricks defina el mercado por sí sola. Puede combinar la experiencia de Crunchy Data con sus propios servicios de analítica, aplicaciones e IA.

AWS sigue siendo otra fuerza importante a través de Amazon Aurora y su cartera más amplia de bases de datos. Microsoft puede combinar bases de datos de Azure, Fabric, servicios de Databricks y su relación con OpenAI.

Este mercado saturado resulta útil para los compradores porque fomenta un desarrollo más rápido. También dificulta las comparaciones de productos. Cada proveedor describe su base de datos como preparada para agentes de IA.

Los compradores necesitan evidencia vinculada a cargas de trabajo reales. Una evaluación útil debería incluir latencia transaccional, pruebas de recuperación, tiempo de creación de ramas, límites de conexión, esfuerzo administrativo y comportamiento bajo demanda variable.

Los equipos también deberían probar el movimiento de datos. Una aplicación puede necesitar registros operativos para analítica, evaluación de modelos o recuperación de información. La arquitectura debería mostrar con qué rapidez esos registros están disponibles y cómo las políticas de gobernanza los acompañan.

Las afirmaciones de los proveedores sobre la adopción de agentes requieren una cautela similar. Una base de datos creada por una herramienta automatizada no necesariamente respalda una aplicación de producción valiosa.

Las métricas importantes son el crecimiento sostenido de las cargas de trabajo, las bases de datos activas en producción, la retención, la fiabilidad y la expansión de clientes. Databricks no ha proporcionado públicamente suficientes detalles para resolver esas cuestiones.

También existe un riesgo de integración estratégica. Los productos adquiridos pueden perder impulso cuando los equipos pasan meses adaptando sistemas de autenticación, facturación, soporte y gobernanza.

Neon siguió publicando actualizaciones de producto después de unirse a Databricks, lo que sugiere un desarrollo activo. Sin embargo, los lanzamientos continuos no demuestran que todos los clientes de Databricks puedan adoptar Lakebase sin compromisos arquitectónicos.

Un análisis independiente describió la adquisición como un paso que acercó a Databricks a los hyperscalers. Una evaluación de bases de datos señaló que las capacidades de PostgreSQL expandieron a Databricks más allá de su competencia tradicional en gestión de datos.

Esa expansión es estratégicamente atractiva, pero eleva las expectativas. Databricks ahora debe competir con proveedores que han operado bases de datos críticas para el negocio durante muchos años.

La adquisición convirtió a Databricks en un participante creíble en esa competencia. La evidencia de producción determinará si se convierte en un líder duradero en bases de datos.

Tres señales mostrarán quién gana terreno

La disponibilidad del producto, la adopción en producción y la integración competitiva determinarán si Neon cambia el mercado.

La primera señal es la adopción de Lakebase tras su disponibilidad general. El interés durante la vista previa puede reflejar experimentación, mientras que el uso en producción requiere revisiones de seguridad, pruebas operativas y compromiso organizativo.

Los clientes deberían buscar implementaciones identificadas que respalden aplicaciones de cara al cliente. Los casos más sólidos incluirán características medibles de la carga de trabajo, requisitos de recuperación e integración con la gobernanza de Databricks.

La expansión repetida dentro de las cuentas existentes de Databricks fortalecería la estrategia de la empresa. Mostraría que los clientes de analítica ven valor en añadir cargas operativas a la misma plataforma.

Una adopción limitada debilitaría la tesis. Sugeriría que las empresas prefieren servicios de bases de datos establecidos, incluso cuando usan Databricks para analítica e IA.

La segunda señal es la respuesta de Google mediante AlloyDB y su plataforma de agentes. Google ya cuenta con una amplia cartera de bases de datos, por lo que su respuesta no necesita referirse directamente a Databricks.

Los indicadores significativos son vínculos más estrechos entre AlloyDB, Gemini, herramientas de agentes, BigQuery y servicios de gobernanza. Google puede hacer de la integración vertical su respuesta más sólida a Databricks.

Sus funciones de IA para PostgreSQL ahora abarcan recuperación vectorial, consultas en lenguaje natural, conexiones con modelos y flujos de trabajo orientados a agentes. Una integración continua fortalecería la posición de Google entre los clientes ya comprometidos con su nube.

Databricks puede responder mediante consistencia multicloud. Si Lakebase se comporta de forma similar en AWS, Azure y Google Cloud, los clientes obtienen una alternativa a la arquitectura de aplicaciones específica de cada proveedor.

Esa afirmación necesita verificación operativa. Las fechas de disponibilidad, la cobertura regional, las funciones de red y las opciones de recuperación ante desastres pueden diferir entre nubes.

La tercera señal es cómo Snowflake y otros proveedores empaquetan PostgreSQL. La adquisición de Crunchy Data por parte de Snowflake confirmó que Databricks no era la única empresa que identificaba las bases de datos operativas como una capa ausente.

Observe si Snowflake Postgres se convierte en un servicio de producción estrechamente conectado a su plataforma de datos. Una fuerte adopción dividiría la demanda empresarial y debilitaría cualquier narrativa simple de dos empresas.

AWS puede presionar a cada participante mediante Aurora, Bedrock y su consolidada base de desarrolladores. Microsoft puede combinar los servicios de bases de datos de Azure con Fabric y Azure Databricks.

Por tanto, la competencia se desarrollará en varias dimensiones. La fiabilidad de las bases de datos sigue siendo fundamental, pero la gobernanza de plataforma, la elección de modelos, el flujo de trabajo de los desarrolladores y la portabilidad entre nubes ahora influyen en la misma compra.

Para los desarrolladores, el beneficio inmediato es una mayor variedad de opciones. Un equipo puede comparar ofertas integradas de PostgreSQL sin abandonar SQL, bibliotecas y herramientas conocidas.

Para los compradores empresariales, la decisión tiene consecuencias más duraderas. La base de datos operativa suele convertirse en el sistema de registro de una aplicación. La plataforma que la rodea puede moldear la seguridad, la analítica y el desarrollo de IA durante años.

Para los equipos de producto de IA, la ramificación de bases de datos merece especial atención. Los agentes que editan software necesitan entornos de datos aislados, credenciales controladas y limpieza automatizada. Una base de datos diseñada para el aprovisionamiento al ritmo humano puede ralentizar todo el flujo de trabajo.

La rivalidad entre databricks y google no se resolverá con un solo benchmark ni una adquisición. Se resolverá mediante decisiones repetidas de producción sobre dónde los agentes almacenan estado y acceden a información gobernada.

La transacción de Neon importa porque cambió el papel de Databricks. La empresa ya no ofrece solo el entorno analítico junto a una base de datos de aplicaciones. Ahora quiere proporcionar ambos.

Google aún mantiene ventajas importantes en alcance de infraestructura y servicios de nube integrados. Databricks ocupa una posición sólida dentro de los equipos de datos empresariales y puede operar en las nubes más grandes.

Esto crea un conflicto productivo. Google quiere que la plataforma en la nube organice la pila de IA. Databricks quiere que la plataforma de datos se convierta en esa capa organizadora.

Los equipos que evalúen cualquiera de las dos vías deberían comenzar con una aplicación real en lugar de una lista de funciones. Prueben el comportamiento transaccional, el aislamiento de ramas, la recuperación, la gobernanza y la integración de modelos bajo la demanda esperada.

Luego pregunte quién controla el contexto más importante. Si la respuesta es el proveedor de nube, la ruta integrada de Google se vuelve atractiva. Si la respuesta es la plataforma de datos, Databricks gana influencia.

La adquisición convirtió esa elección arquitectónica en una decisión de compra inmediata. Siga de cerca los despliegues de Lakebase en producción, una integración más profunda con AlloyDB y el lanzamiento de PostgreSQL de Snowflake. Estas señales mostrarán si Databricks ha construido un negocio de bases de datos duradero o si simplemente ha entrado en una carrera concurrida.