Databricks adquire a Neon, empresa especializada em Postgres serverless

• A Databricks fechou um acordo para adquirir a Neon, que oferece Postgres serverless com foco em desenvolvedores
• A Neon oferece uma plataforma de banco de dados serverless otimizada para desenvolvedores e sistemas de IA por meio de uma arquitetura com separação entre storage e compute
• Com a adoção da Neon, a proporção de bancos de dados gerados por agentes de IA cresceu rapidamente de 30% para mais de 80%
• Databricks e Neon compartilham uma filosofia open source e um DNA de inovação em infraestrutura
• Mesmo após a aquisição, o suporte à plataforma Neon e seu roadmap voltado ao futuro serão reforçados com os recursos da Databricks

---

Anúncio da aquisição e seu significado

• A Databricks fechou um acordo para adquirir a Neon, que oferece Postgres serverless com foco em desenvolvedores
• Os cofundadores da Neon estão entre os poucos especialistas no mundo capazes de projetar o Postgres com uma arquitetura de separação total entre storage e compute
• Essa equipe vem se concentrando em oferecer uma plataforma de Postgres serverless para dar suporte a desenvolvedores em larga escala na era da IA

Missão de inovação baseada em Postgres

• Os cofundadores da Neon se uniram há cerca de quatro anos para reinventar estruturas de banco de dados consideradas ultrapassadas
• Os principais objetivos eram os seguintes
  • Antecipar a padronização de fato do Postgres e estabelecer a visão de uma plataforma serverless
  • Focar em velocidade para que desenvolvedores possam criar novas instâncias em segundos
  • Resolver preocupações com overprovisioning e underprovisioning por meio de escalabilidade automática e simplificação das operações do banco de dados
  • Facilitar testes e experimentação com bancos de dados por meio de suporte imediato a branching e forking
• A equipe da Neon alcançou esses objetivos criando uma arquitetura que permite escalabilidade independente de storage e compute
• Após o lançamento, os desenvolvedores elogiaram a velocidade, a simplicidade e os recursos de branching/forking no estilo Git

Mudanças na era dos agentes de IA

• Desde o GA da Neon, os agentes de IA passaram de 30% de todas as criações de DB para mais de 80% recentemente
• Os agentes de IA passaram a ter necessidades semelhantes às dos desenvolvedores
• Os pontos fortes da Neon são os seguintes
  • Ecossistema open source do Postgres: como os LLMs mais recentes foram treinados com dados de Postgres, os agentes de IA são proficientes no uso da Neon
  • Rapidez: como é exigida uma velocidade maior do que a humana, o provisionamento ultrarrápido de instâncias é essencial
  • Escalabilidade flexível e preço: a estrutura serverless separada permite custos extremamente baixos e suporte a muitos agentes de IA
  • Branching e forking: facilita experimentação e validação para as tentativas dinâmicas e imprevisíveis dos agentes de IA

DNA compartilhado entre Databricks e Neon

• Os fundadores Nikita Shamgunov, Heikki Linnakangas e Stas Kelvich são especialistas renomados em tecnologia de banco de dados
• Eles trazem ampla experiência e originalidade, incluindo passagens por SingleStore e atuação como committers do Postgres
• Tanto a Databricks quanto a Neon valorizam inovação tecnológica de ponta na camada de infraestrutura e os valores open source
• Tanto o Apache Spark quanto o Postgres têm em comum o fato de serem projetos open source iniciados na UC Berkeley

Visão futura e benefícios para os usuários

• O mercado de bancos de dados OLTP (cerca de US$ 100 bilhões) ainda é dominado por produtos de décadas atrás
• Agora é o momento de desenvolvedores e agentes de IA liderarem a inovação
• Databricks e Neon têm como objetivo a melhor plataforma de banco de dados para desenvolvedores e amigável a agentes de IA
• Clientes e parceiros atuais da Neon podem esperar suporte contínuo e inovação, além da concretização do roadmap
• Com os recursos da Databricks, estão previstos fortalecimento da plataforma e crescimento estável
• A visão futura será compartilhada em detalhes no Data + AI Summit (São Francisco, de 9 a 12 de junho)

[GN⁺]

Comentários do Hacker News

• Acho que data warehousing está se comoditizando rapidamente graças ao open source. Uma empresa que conheço armazenava mais de 2 petabytes de dados no Cloudera, mas em vez de migrar para a nuvem (Databricks), construiu sua própria plataforma de analytics com Iceberg, Trino e Superset e reduziu os custos em 5 vezes. Operadores k8s de nível enterprise agora já são bons o bastante, e S3 on-premises também é excelente. Também dá para ter bom hardware e rede, como servidores com 128 CPUs e 1 TB de memória. Além do Trino, StarRocks e ClickHouse também oferecem charts Helm/operadores k8s de nível enterprise. A avaliação de US$ 60 bilhões da Databricks é problema deles. Eles precisam justificar esse preço, e o próprio negócio principal deles também está se comoditizando. A Neon preenche uma lacuna da linha de produtos deles, que não tinha um banco operacional (orientado a linhas)
  • Do ponto de vista enterprise, não é comoditização. Meu emprego anterior não permitia software open source, nem empresas que talvez nem existam daqui a 10 anos, nem empresas que mantenham nossos dados fora do nosso tenant. A política de preço “fale conosco” era até bem-vinda, e adotar a Databricks foi um dos meus 3 maiores resultados, porque eu não precisava mais me preocupar com a plataforma de dados. O risco de adotar uma plataforma nova é grande demais, então (qualquer projeto open source) não é confiável. Uma vez adotamos uma solução de startup, mas como ela usava MongoDB e o time de operações não tinha capacidade, em vez de aprender contratamos um serviço com suporte completo, como Atlas. Em vez de um firewall do Azure que ninguém conhecia, usamos apenas firewalls que já conhecíamos, e seguimos com vários contratos. Redução de contratação, ponto único de contato, eficiência operacional. A licença da startup custa US$ 5–10 mil por ano, mas o suporte custa muito mais, tipo US$ 40 mil. Startup e enterprise são mundos completamente diferentes
  • Estou analisando clientes com dados na casa dos terabytes usando StarRocks open source com operador k8s, e no meu ambiente sinto que quase não preciso de Databricks
  • Uso ClickHouse há alguns anos sem problemas. O conjunto de recursos é amplo, e é um banco de dados que transmite confiança. O recurso de dicionário externo facilita a integração com outros datastores, como Postgres e Redis
  • Se alguém estiver procurando uma alternativa open source ao Cloudera baseada em operadores Kubernetes, venho desenvolvendo a stackable.tech há 5 anos. O lado de S3 open source on-premises é problemático. Não recomendo MinIO, e fora isso quase não há soluções com suporte enterprise
  • Data warehousing já se comoditizou há décadas. Existe um longo histórico de métricas de preço e performance, e o produto SnowBricks não atende a isso. É só uma diferença entre venda empurrada e venda mais suave
  • Não entendo por que alguém compraria um banco operacional da Databricks. Parece apenas a Databricks se debatendo para manter seu valor de mercado
  • Se a Databricks simplesmente precisasse de um banco row-oriented, teria montado um Postgres por conta própria. Gastar tanto dinheiro com a Neon é um sinal de que queria algo especial nela, como o “storage e compute escaláveis de forma independente”
  • Fiquei curioso sobre o que usam para ETL
• Me candidatei à Neon na semana passada, saiu a notícia da aquisição e hoje de manhã já recebi a rejeição. Foi a rejeição mais feliz da minha vida. Seria a terceira vez seguida que eu quase entraria numa empresa que acabou sendo adquirida, então agora eu só quero estabilidade. Parabéns ao time da Neon. Gosto da Neon e uso o produto, e espero que essa aquisição não mude tudo demais
  • Entrei na Kenna Security antes da aquisição, e um mês depois a Cisco comprou a empresa. Foi uma experiência realmente horrível, e eu nunca mais trabalharia nem numa empresa com a liderança da Kenna nem na Cisco
  • Tive a experiência oposta. Entrar numa empresa na época de aquisição foi o momento mais interessante. No meu caso, a experiência de integração pós-aquisição fez com que eu fosse abordado por recrutadores com frequência
  • Estive num processo de aquisição no meu primeiro ano como gerente de engenharia e ajudei a selecionar quem ficaria, sobrevivi a duas rodadas de demissão e participei da reorganização dos times. O moral despencou e a cultura organizacional não combinava em nada. Sofri um burnout pesado, fiquei alguns meses parado e agora estou feliz de novo trabalhando como IC
  • Minha aposta é que o time da Neon vai ser incorporado à tecnologia Online Tables da Databricks. Isso faz sentido do ponto de vista de produto
  • Se alguém entrou na Neon numa avaliação antiga e acabou de concluir o vesting, deve ter recebido uma bolada de repente; fiquei curioso sobre como deve ser isso
• Databricks é o software mais irritante e lixo que já usei. Acho curioso que alguém use isso por vontade própria
  • A Databricks começou em 2013, quando o Spark ainda deixava a desejar, e tornou o Spark melhor e mais rápido. O produto ainda gira em torno de Spark, mas acho que a combinação Iceberg + DuckDB faz mais sentido para 95% das empresas. É mais barato, mais rápido e mais fácil de lidar, e na Definite também estamos construindo uma plataforma de dados com essa premissa (incluindo ETL, BI e Data Lake)
  • Databricks é o Jira dos dados. Ninguém quer usar, é mais ou menos, e os recursos todos parecem desajeitados porque tentaram agradar todo tipo de usuário. Hoje já existem alternativas muito melhores, então eu jamais escolheria Databricks por conta própria
  • Acho realmente difícil concordar. Vindo do mundo Hadoop, Databricks é uma utopia. É estável, rápida e escala muito bem com grandes datasets. Só que meu maior problema é o preço absurdo
  • Eu gostava da plataforma Databricks no passado. Em 2020–2021, em comparação com AWS, Azure e Snowflake, quase só a Databricks era uma alternativa razoável. Hoje virou uma bagunça, com excesso de recursos, mudanças frequentes, aquisições e até os nomes das funcionalidades estão confusos
  • Então ainda existia mercado para aquele tipo de software estilo IBM (“todo mundo usa, então a gente também usa”)
  • Sinceramente, Databricks é um produto muito sem graça. Pensando no fim dos anos 2010, Spark-as-a-Service era excelente, numa época em que empresas falhavam em operar Spark com estabilidade por conta própria. Os hyperscalers também tinham serviços de primeira linha bem fracos, e embora houvesse problemas como incompatibilidades do formato de notebook da Databricks com Jupyter, clusters on-prem instáveis eram uma dor de cabeça ainda maior, então eu pagava o prêmio sem hesitar. Naquela época, a Databricks era um ótimo negócio de US$ 1 bilhão. Mas não dava para virar unicórnio só com Spark-aaS. O AWS EMR vinha chegando devagar como concorrente e, no fim, a Databricks apostou tudo em inflar o produto para manter o crescimento, com uma chuva de buzzwords como data, lake e house. Em 2025, o declínio da Databricks é um retrato amargo da enshittification. Talvez um dia o Larry Ellison compre a empresa e ela desapareça do mercado. Não entendo por que alguém escolhe Databricks para projetos novos hoje, mas empresas enterprise que usam há mais de 5 anos não saem fácil. A participação de mercado vai cair, mas por um tempo ainda vai continuar ganhando dinheiro. Esse é o ciclo do setor, e no fim a entropia vence. Não vou odiar demais. Foi uma empresa que construiu uma história bem respeitável
  • Eles forçam muito a ideia de serverless, mas há tantas limitações e armadilhas escondidas que isso é enlouquecedor
  • Sempre me perguntei se hospedar Spark foi realmente tão revolucionário. E se o próprio Spark não é complexo demais para 90% do processamento de dados em empresas tradicionais. Não consigo entender por que essa empresa vale tanto
  • Se você desativa cookies, o site simplesmente não carrega. Isso é um red flag gravíssimo. Se a empresa não consegue nem fazer um site, não dá para acreditar que vá fazer um bom produto digital
• Databricks é ruim no nível da Oracle. Tenho certeza de que vai estragar a Neon ou deixá-la cara demais. No médio e longo prazo, pretendo procurar alternativas à Neon
  • A estratégia de M&A da Databricks é sufocar as empresas adquiridas. Ela vem sofrendo com a grande mudança trazida pelo open source, como Iceberg e DuckDB. Está tentando inovar via aquisições, mas por causa da cultura interna as empresas compradas acabam desmoronando. Posso estar enviesado por vir do setor de big data (ex-Snowflake), mas é nítido que o open source está ganhando cada vez mais força. Estou muito curioso para ver no que isso vai dar
• Citação da matéria original: “Quando a Neon entrou em GA no ano passado, 30% dos bancos de dados criados eram feitos por agentes de IA, mas quando olhamos de novo recentemente, essa proporção já passou de 80%. Isso significa que a IA criou 4 vezes mais bancos do que humanos.” Isso aciona vários alarmes. Parece que a Databricks quer empacotar Postgres como uma solução de IA. O mundo anda mesmo curioso
  • Fiquei curioso para saber quantos desses bancos estão realmente em uso ativo
• Parabéns ao time da Neon. Gostei muito do que construíram. Mas, sinceramente, não vejo relação nem sinergia com a Databricks, e espero que a Neon continue existindo como produto separado. Caso contrário, o mercado perde mais um fornecedor sólido de Postgres
  • Como a dependência de Azure é alta, acho que ela não vai desaparecer tão cedo. Parece mais um movimento da Databricks para expandir além de bancos analíticos e entrar também no território dos bancos transacionais
  • No FAQ dizem que vai operar de forma independente, mas acho que na prática o desfecho é bem previsível
• Lembro do primeiro post da Neon no HN. Já naquela época comentei que era uma ideia excelente e, embora eu ainda não tivesse precisado usar, achava que um dia usaria. Mas quando vejo notícias de aquisição assim, bate um ceticismo. Fico preocupado que agora o foco passe dos usuários para os proprietários. Em teoria esses interesses deveriam estar alinhados, mas na prática raramente foi o caso
  • Eu também lembro do primeiro post da Neon. A separação entre storage e compute era algo novo, e eu até fiz perguntas sobre o Pageserver. Dois anos depois, acabei eu mesmo trabalhando em storage desagregado no banco Turso. Parabéns de novo ao time da Neon
  • Eu também travo um pouco quando vejo essa aquisição. É difícil acreditar que priorizar usuários de IA esteja alinhado com os interesses dos desenvolvedores. Espero que a tecnologia ligada ao core do PostgreSQL receba ajuda da comunidade open source
• Parabéns ao time da Neon. Produto excelente. Claro, quando há investimento de VC, esse tipo de desfecho parece inevitável. Espero que o Nikita e os outros não sejam absorvidos pela cultura da Databricks e continuem firmes
• Esse é um desenvolvimento realmente interessante. Acho que essa forma de convergência entre OLTP e OLAP está na direção certa. Tive experiência com o OP construindo um sistema HTAP na SingleStore. Tentamos fazer OLTP e OLAP em um único banco de dados (uma cópia só para atender os dois), mas HTAP não funcionou tão bem assim. O caminho parece ser OLTP em Postgres, OLAP em data warehouse/lake, e uma replicação eficiente entre os dois. Replicação síncrona é difícil. Armazenamento colunar não lida bem com escritas OLTP. Estou curioso para ver se Databricks e Neon conseguem viabilizar o cenário de “usar diretamente tabelas Postgres mais recentes no Unity Catalog” (sem passar por Debezium, Kafka, Flink ou Iceberg, com o Spark mantendo o estado do Iceberg)
  • Pergunta se OP se refere ao fundador da Neon, Nikita Shamgunov (antes fundador da MemSQL/SingleStore)
• Parabéns ao time da Neon. Sinceramente, é um pouco decepcionante. Eu esperava que a Neon ocupasse o espaço deixado quando a CockroachDB mudou para business source. Com a aquisição pela Databricks, a Neon parece menos atraente. É difícil confiar que uma big tech vá cuidar de uma infraestrutura importante. Há demanda suficiente por um PostgreSQL “moderno”, mas nenhuma das alternativas que examinei continua realmente fiel às raízes (em preço, compatibilidade, abertura do código etc.). Ao procurar alternativas ao Postgres, comparei o seguinte (1) AWS RDS: eu já usava, mas era caro e tinha problemas de escalabilidade e operação (2) AWS Aurora: resolve parte dos problemas operacionais, mas traz outras desvantagens, e tem limitações parecidas com outras alternativas Postgres wire-compatible (3) CockroachDB: era muito interessante, mas tinha problemas de compatibilidade profunda e com a toolchain; na época ainda era open source (4) Neon: parecia ainda imatura e acabei não adotando, mas era interessante e parecia capaz de resolver muitos problemas (5) Yugabyte: também uma tecnologia interessante, mas com vários problemas de compatibilidade Também considerei hospedar Postgres diretamente, mas o peso operacional do PostgreSQL no Kubernetes me fez hesitar. Replicação própria e recursos operacionais ainda pareciam pouco maduros, e em upgrades era muito incômodo ter que descarregar e recarregar todos os dados. Escalar e automatizar também não era fácil
  • Em resposta à comparação com o Yugabyte por usar um engine de consulta baseado em Postgres, lembra que a Neon é Postgres de fato
  • Compartilha a experiência curta de que “a melhor alternativa moderna ao Postgres é o próprio Postgres (daqui a 5 anos)”
  • Gostaria de ouvir mais sobre quais são essas “mesmas desvantagens” das outras alternativas PostgreSQL wire-compatible