Databricks acuerda adquirir Neon, especialista en Postgres serverless

• Databricks llegó a un acuerdo para adquirir Neon, que ofrece Postgres serverless centrado en desarrolladores
• Neon ofrece una plataforma de base de datos serverless optimizada para desarrolladores y sistemas de IA mediante una arquitectura con separación entre almacenamiento y cómputo
• Tras la adopción de Neon, la proporción de bases de datos generadas por agentes de IA creció rápidamente del 30% a más del 80%
• Databricks y Neon comparten una filosofía open source y un ADN de innovación en infraestructura
• Incluso después de la adquisición, el soporte de la plataforma Neon y su hoja de ruta orientada al futuro se fortalecerán con los recursos de Databricks

---

Anuncio de la adquisición y su importancia

• Databricks llegó a un acuerdo para adquirir Neon, que ofrece Postgres serverless centrado en desarrolladores
• Los cofundadores de Neon son de los pocos expertos en el mundo capaces de diseñar Postgres con una arquitectura de separación total entre almacenamiento y cómputo
• Este equipo se ha enfocado en ofrecer una plataforma de Postgres serverless para dar soporte a desarrolladores a gran escala en la era de la IA

Misión de innovación basada en Postgres

• Los cofundadores de Neon se unieron hace unos cuatro años con la intención de transformar una arquitectura de bases de datos ya anticuada
• Los objetivos principales eran los siguientes
  • Anticipar la estandarización de facto de Postgres y establecer la visión de una plataforma serverless
  • Poner el foco en la velocidad para que los desarrolladores puedan crear nuevas instancias en segundos
  • Resolver la preocupación por el sobreaprovisionamiento y el subaprovisionamiento mediante el escalado automático de la base de datos y la simplificación de tareas
  • Facilitar las pruebas y la experimentación en bases de datos con soporte inmediato para branching y forking
• El equipo de Neon logró estos objetivos creando una arquitectura con escalado independiente de almacenamiento y cómputo
• Desde su lanzamiento, los desarrolladores han elogiado su velocidad, simplicidad y las funciones de branching/forking al estilo Git

Cambios en la era de los agentes de IA

• Desde el GA de Neon, los agentes de IA representaban el 30% de toda la creación de bases de datos, y recientemente esa cifra aumentó a más del 80%
• Los agentes de IA llegaron a tener necesidades similares a las de los desarrolladores
• Las fortalezas de Neon son las siguientes
  • Ecosistema open source de Postgres: como los LLM más recientes fueron entrenados con datos de Postgres, los agentes de IA usan Neon con soltura
  • Rapidez: como se requiere una velocidad mayor que la humana, el aprovisionamiento ultrarrápido de instancias es esencial
  • Escalado flexible y precio: gracias a una arquitectura serverless desacoplada, ofrece costos muy bajos y puede dar soporte a numerosos agentes de IA
  • Branching y forking: facilita la experimentación y validación para los intentos cambiantes de los agentes de IA

El ADN compartido de Databricks y Neon

• Los fundadores Nikita Shamgunov, Heikki Linnakangas y Stas Kelvich son reconocidos expertos en tecnología de bases de datos dentro de la industria
• Cada uno aporta una amplia experiencia y originalidad, incluyendo SingleStore y su labor como committers de Postgres
• Tanto Databricks como Neon valoran la innovación tecnológica de punta en la capa de infraestructura y los principios open source
• Tanto Apache Spark como Postgres tienen el vínculo de ser proyectos open source iniciados en UC Berkeley

Visión a futuro y beneficios para los usuarios

• El mercado de bases de datos OLTP (de alrededor de 100 mil millones de dólares) sigue dominado actualmente por productos de hace décadas
• Ahora es el momento de que los desarrolladores y los agentes de IA impulsen la innovación
• Databricks y Neon apuntan a construir la mejor plataforma de bases de datos para desarrolladores y amigable con agentes de IA
• Los clientes y socios actuales de Neon pueden esperar soporte e innovación continuos y la ejecución de la hoja de ruta
• Con los recursos de Databricks, se garantizarán el fortalecimiento de la plataforma y un crecimiento estable
• Compartirán en detalle su visión futura en el Data + AI Summit (San Francisco, del 9 al 12 de junio)

[GN⁺]

Comentarios en Hacker News

• Creo que el data warehousing se está comoditizando rápidamente gracias al open source. Una empresa que conozco tenía más de 2 petabytes de datos almacenados en Cloudera, pero en vez de migrar a la nube (Databricks), construyó su propia plataforma de analítica con Iceberg, Trino y Superset, y ahorró 5 veces en costos. Los operadores de k8s de nivel enterprise ya son lo suficientemente buenos, y el S3 on-premises también es excelente. También se puede conseguir muy buen hardware y networking, como servidores con 128 CPU y 1 TB de memoria. No solo Trino, también StarRocks y Clickhouse ofrecen charts/operadores Helm de k8s de nivel enterprise. La valuación de Databricks de 60 mil millones de dólares es problema suyo. Tienen que justificar ese precio, y su negocio principal también se está comoditizando. Neon cubre el hueco de no tener una base de datos operacional (orientada a filas) en su portafolio
  • Desde la perspectiva enterprise, no se está comoditizando. En mi trabajo anterior no permitían software open source, ni empresas que quizá no existan en 10 años, ni compañías que almacenen nuestros datos fuera de nuestro tenant. Incluso agradecían la política de precios de “llame para consultar”, y adoptar Databricks fue uno de mis 3 principales logros porque ya no había que preocuparse por la plataforma de datos. El riesgo de introducir una plataforma nueva es demasiado alto, así que (cualquier proyecto open source) no es confiable. Una vez adoptamos una solución de startup, pero como usaba MongoDB y al equipo de operaciones le faltaba capacidad, en vez de aprender contrataron un servicio con soporte completo como Atlas. En lugar de un firewall de Azure que no conocían, solo usaron firewalls conocidos, y además cerraron varios contratos. Menos contrataciones, un solo punto de contacto y eficiencia operativa. La licencia de una startup cuesta entre 5 y 10 mil dólares al año, pero el soporte cuesta mucho más, como 40 mil dólares. Las startups y las empresas enterprise viven en mundos completamente distintos
  • Estamos usando StarRocks open source con un operador de k8s para analizar datos de clientes a escala de terabytes, y en mi entorno siento que casi no necesitamos Databricks
  • Llevo varios años usando ClickHouse sin problemas. Tiene un abanico amplio de funcionalidades y transmite confianza como base de datos. Gracias a la función de diccionario externo (external dictionary), es fácil integrarlo con otros datastores como Postgres y Redis
  • Si buscan una alternativa open source a Cloudera basada en operadores de Kubernetes, llevo 5 años desarrollando stackable.tech. El lado de S3 open source on-premises sí es problemático. No recomiendo MinIO, y fuera de eso casi no hay soluciones realmente aptas para enterprise
  • El data warehousing se comoditizó hace décadas. Hay una larga historia de métricas de precio y rendimiento, y los productos SnowBricks no dan la talla aquí. Solo cambia si te lo venden a la fuerza o de forma más suave
  • No entiendo por qué alguien compraría una base de datos operacional a Databricks. Solo parece un intento desesperado de Databricks por sostener su valor de mercado
  • Si Databricks simplemente necesitara una base de datos de filas, habría armado Postgres por su cuenta. Que haya pagado tanto dinero por Neon es señal de que quería algo especial de Neon, como su “storage y compute que escalan de forma independiente”
  • Me da curiosidad saber qué usan para ETL
• La semana pasada postulé a neon, salió la noticia de la adquisición y hoy en la mañana me llegó el rechazo de inmediato. Ha sido la mejor experiencia de rechazo de mi vida. Esta sería la tercera vez seguida que casi entro a una empresa que termina siendo adquirida, así que ahora solo quiero estabilidad. Felicidades al equipo de neon. Me gusta neon y lo uso, y ojalá esta adquisición no lo cambie demasiado
  • Yo entré a Kenna Security antes de su adquisición y un mes después la compró Cisco. Fue una experiencia realmente horrible y nunca volvería a trabajar ni en una empresa con liderazgo de Kenna ni en Cisco
  • Yo tuve la experiencia opuesta. Entrar durante una adquisición fue la etapa más interesante. En mi caso, la experiencia de integración postadquisición hizo que luego me buscaran seguido
  • Estuve en un proceso de adquisición cuando era engineering manager de primer año, y ayudé a seleccionar a quién se quedaban tras dos rondas de despidos y a reorganizar equipos. La moral estaba por el piso y la cultura organizacional no encajaba para nada. Terminé con un burnout fuerte, descansé unos meses y ahora volví feliz como IC
  • Mi apuesta es que el equipo de neon se integrará a la tecnología de Online Tables de Databricks. También tiene sentido a nivel de producto
  • Me pregunto cómo se sentirá si alguien entró cuando neon tenía una valuación antigua y justo acababa de terminar su vesting; de pronto le debió caer una suma considerable
• Databricks es el software más irritante y basura que he usado en mi vida. Me sorprende que alguien lo use por voluntad propia
  • Databricks empezó en 2013, cuando Spark dejaba mucho que desear, e hizo que Spark fuera mejor y más rápido. El producto sigue girando alrededor de Spark, pero creo que la combinación de Iceberg y DuckDB le queda mejor al 95% de las empresas. Es más barata, más rápida, más fácil de manejar, y en Definite nosotros también estamos construyendo una plataforma de datos bajo esa premisa (incluyendo ETL, BI y Data Lake)
  • Databricks es el Jira de los datos. Nadie quiere usarlo, no es muy bueno, y por intentar adaptarse a todo tipo de usuario terminó lleno de funciones torpes. Ahora hay muchas alternativas mucho mejores, así que yo nunca elegiría Databricks por decisión propia
  • La verdad me cuesta muchísimo estar de acuerdo. Viniendo del mundo Hadoop, Databricks es una utopía. Es estable, rápido y escala muy bien con datasets grandes. Mi mayor queja, eso sí, es que es demasiado caro
  • Antes me gustaba la plataforma de Databricks. En 2020~2021 era prácticamente la única alternativa razonable frente a AWS, Azure y Snowflake. Hoy está por todos lados, llena de funciones, cambios frecuentes y adquisiciones, y hasta los nombres de las funciones son un desastre
  • Resulta que todavía quedaba mercado para software tipo IBM (todos lo usan, así que nosotros también)
  • Honestamente, Databricks es un producto muy aburrido. Si pienso en fines de los 2010, Spark-as-a-Service era excelente, y las empresas fracasaban al intentar operar Spark de forma estable por su cuenta. Los hyperscalers también tenían servicios de primera generación bastante flojos, y aunque había problemas como la compatibilidad de los notebooks de Databricks con Jupyter, la inestabilidad de los clústeres on-prem era un dolor mucho mayor, así que pagar el premium valía la pena. En ese entonces Databricks ya era un gran negocio de mil millones de dólares. Pero no se podía llegar a unicornio solo con Spark-aaS. AWS EMR venía persiguiéndolo lentamente como competidor, y al final Databricks también se lanzó de lleno a inflar su producto como estrategia de crecimiento: datos, lake, house, una lluvia de buzzwords. En 2025, la decadencia de Databricks es una cara amarga de la enshittification. Algún día Larry Ellison quizá la compre y desaparezca del mercado. No entiendo por qué alguien elige Databricks para proyectos nuevos hoy, pero las empresas que lo llevan usando más de 5 años no van a salir fácilmente. Su cuota de mercado caerá, pero seguirá ganando dinero por un tiempo. Así funciona el ciclo de la industria y, al final, la entropía siempre gana. Tampoco lo odiaré tanto. Fue una empresa con una historia bastante buena
  • Hablan demasiado de serverless, pero tiene tantos límites y trampas ocultas que es desesperante
  • Dudo que hospedar Spark haya sido tan revolucionario. Y siempre he sospechado que Spark en sí es demasiado complejo para el procesamiento de datos del 90% de las empresas tradicionales. No entiendo por qué esta empresa vale tanto
  • Si desactivas las cookies, el sitio web ni siquiera carga. Eso es una red flag gravísima. Si no pueden hacer ni un sitio web, no me hace pensar que puedan hacer un buen producto digital
• Databricks es tan malo como Oracle. Estoy seguro de que arruinará Neon o lo volverá caro. A mediano y largo plazo pienso buscar alternativas a Neon
  • La estrategia de M&A de Databricks está estructurada para asfixiar a las empresas que adquiere. Además está pasándola mal con el gran cambio del open source, como Iceberg y DuckDB. Está intentando innovar vía adquisiciones, pero por su cultura empresarial las compañías compradas se terminan desmoronando. Puede que esté sesgado porque vengo de la industria de big data (ex-Snowflake), pero sí se ve clarísimo que el open source viene ganando fuerza. Tengo mucha curiosidad por ver cómo evoluciona este cambio
• Cita del artículo original: “El año pasado, cuando Neon pasó a GA, el 30% de las bases de datos eran creadas por agentes de IA; recientemente volvimos a mirar y esa proporción ya superaba el 80%. Eso significa que la IA creó 4 veces más bases de datos que los humanos.” Estos datos hacen sonar muchas alarmas. Parece que Databricks quiere empaquetar Postgres como una solución para IA. Qué raro está el mundo últimamente
  • Me pregunto cuántas de esas bases de datos siguen en uso activo
• Felicidades al equipo de Neon. Me gusta mucho lo que construyeron. Pero sinceramente no percibo la relación ni la sinergia con Databricks, y ojalá Neon siga existiendo como producto separado. Si no, el mercado pierde otro proveedor claro de Postgres
  • Como depende mucho de Azure, no creo que desaparezca de inmediato. Más bien parece que Databricks quiere expandirse, no solo a bases de datos analíticas sino también al terreno de las transaccionales
  • En el FAQ dicen que operará de manera independiente, pero en la práctica creo que el resultado es bastante obvio
• Recuerdo el primer post que el equipo de Neon publicó en HN. Ya entonces comenté que era una idea genial, y aunque todavía no había necesitado usarlo directamente, pensaba que algún día lo haría. Pero al ver noticias de adquisiciones como esta, me entra el escepticismo. Me preocupa que ahora se enfoquen más en la posición de los dueños que en la de los usuarios. En teoría ambas deberían alinearse, pero rara vez pasa en la práctica
  • Yo también recuerdo ese primer post de Neon. La separación entre storage y compute me pareció novedosa, e incluso hice preguntas sobre Pageserver. Dos años después, yo mismo terminé trabajando en un storage desacoplado similar en la base de datos Turso. Mis felicitaciones de nuevo al equipo de Neon
  • La noticia de la adquisición también me hace detenerme. Me cuesta creer que priorizar a usuarios de inteligencia artificial alinee sus intereses con los de los desarrolladores. Espero que la tecnología relacionada con el núcleo de PostgreSQL reciba apoyo de la comunidad open source
• Felicidades al equipo de Neon. Un gran producto. Claro, si recibes apoyo de VC, este desenlace es casi inevitable. Ojalá Nikita y los demás no terminen absorbidos por la cultura de Databricks y se mantengan firmes
• Este es un desarrollo realmente interesante. Creo que esta forma de convergencia entre OLTP y OLAP va en la dirección correcta. Trabajé con el OP construyendo un sistema HTAP en SingleStore. Intentamos hacer OLTP y OLAP en una sola base de datos (soportando ambos con una sola copia), pero HTAP no terminó de funcionar bien. El OLTP debería quedar en Postgres, el OLAP en un data warehouse/lake, y la replicación entre ambos tiene que diseñarse de forma eficiente. La replicación síncrona es difícil. Los almacenes orientados a columnas no reciben bien las escrituras de OLTP. Tengo curiosidad por ver si Databricks y Neon pueden hacer realidad el escenario de “usar directamente tablas actualizadas de Postgres en Unity Catalog” (sin pasar por Debezium, Kafka, Flink ni Iceberg, con Spark manteniendo el estado de Iceberg)
  • Preguntan si OP se refiere a Nikita Shamgunov, fundador de Neon (antes fundador de MemSQL/SingleStore)
• Felicidades al equipo de Neon. Sinceramente me da algo de pena. Esperaba que Neon llenara el vacío que dejó CockroachDB al pasarse a business source. Tras ser adquirida por Databricks, Neon se siente menos atractiva. Me cuesta confiar en que una gran empresa se haga cargo de infraestructura importante. Hay suficiente demanda para un PostgreSQL “moderno”, pero entre las alternativas directas ninguna se aleja mucho del tronco original (ya sea por precio, compatibilidad o si el código es abierto). Al buscar alternativas a Postgres comparé lo siguiente
  (1) AWS RDS ya lo usábamos, pero era caro y tenía problemas de escalabilidad y operación
  (2) AWS Aurora resolvía parte de los problemas operativos, pero traía otras desventajas, y tenía limitaciones similares a otras alternativas de Postgres wire-compatible
  (3) CockroachDB era muy interesante, pero tenía problemas de compatibilidad con la toolchain y de compatibilidad profunda; en ese momento todavía era open source
  (4) Neon todavía parecía inmaduro, así que no lo adoptamos, pero se veía interesante y parecía capaz de resolver muchos problemas
  (5) Yugabyte también tenía tecnología interesante, pero presentaba varios problemas de compatibilidad
  También consideramos hospedar Postgres por nuestra cuenta, pero nos preocupaba la carga de operar Kubernetes y Postgres nosotros mismos. Las capacidades propias de replicación y operación todavía eran poco maduras, y al actualizar resultaba muy engorroso descargar y volver a cargar todos los datos. Escalar o automatizar no era fácil
  • Sobre comparar Yugabyte porque su motor de consultas parece basarse en Postgres, recuerdan que Neon sí es Postgres
  • Comparte su experiencia de corto plazo diciendo que “la mejor alternativa moderna a Postgres es el propio Postgres (dentro de 5 años)”
  • Quisiera escuchar más sobre cuáles son esas “mismas desventajas” de otras alternativas PostgreSQL wire-compatible