from Hacker News

Databricks acquires Neon

by davidgomes on 5/14/25, 10:10 AM with 226 comments

  • by jamesblonde on 5/14/25, 2:05 PM

    Data warehousing is quickly becoming a commodity through open-source. I know a company who had 2PBs+ of data in Cloudera. But instead of moving to the cloud (and Databricks), they saved 5X costs by building their own analytics platform with Iceberg, Trino and Superset. The k8s operators are enterprise quality now. On-premises S3 is good, too. You can have great hardware (servers with 128 cpus and 1 TB) and networking. It's not just Trino. StarRocks and Clickhouse have enterprise grade k8s helm charts/operators. That 60bn valuation is an albtross on Databrick's neck - their pricing will have to justify it, and their core business is commoditizing.

    Neon filled their product gap of not having an operational (row-oriented) DB.

  • by Robdel12 on 5/14/25, 12:32 PM

    I applied to neon last week and then the news broke about the acquisition. They rejected it this morning — I have never been happier to receive a rejection to an application.

    This would’ve been three acquisitions straight for me and… I’m okay, they’re awful. I just want stability.

    Congrats to the neon team! I use and love neon. Really hope this doesn’t change them too much.

  • by flanked-evergl on 5/14/25, 10:45 AM

    Maybe unrelated but Databricks is the most annoying garbage I have ever had to use. It fascinates me how anyone uses it by choice.

  • by acd10j on 5/14/25, 11:26 AM

    Databricks is Oracle-level bad. They will definitely ruin Neon or make it expensive. In the medium to long term, I will start looking for Neon alternatives.

  • by everfrustrated on 5/14/25, 3:52 PM

    From the actual article

    >As Neon became GA last year, they noticed an interesting stat: 30% of the databases were created by AI agents, not humans. When they looked at their stats again recently, the number went from 30% to over 80%. That is, AI agents were creating 4 times more databases versus humans.

    For me this has alarm bells all over it. Databricks is trying to pump postgres as some sort of AI solution. We do live in weird times.

  • by higeorge13 on 5/14/25, 10:56 AM

    Congratz to neon team (i like what they built), but i don’t see the value or relation to databricks. I hope neon will continue as a standalone product, otherwise we lose a solid postgres provider from the market.

  • by timmg on 5/14/25, 10:56 AM

    I remember the first post by the Neon team here on HN. I think I commented at the time that I thought it was a great idea. I’ve never had a need to use them yet, but thought I always would.

    Cynically, am I the only one who takes pause because of an acquisition like this? It worries me that they will need to be more focused on the needs of their new owners, rather than their users. In theory, the needs should align — but I’m not sure it usually works out that way in practice.

  • by beoberha on 5/14/25, 2:22 PM

    Congrats to the Neon team. They make an awesome product. Obviously it’s sad to see this, but it’s inevitable when you’re VC funded. Let’s hope Nikita and co remain strong and don’t let Databricks bit.io them.

  • by kjuulh on 5/14/25, 11:32 AM

    Congratulations to the Neon team.

    To be honest this is a little sad for me. I'd hoped that Neon would be able to fill the vacuum left by CockroachDB going "business source"

    Being bought by DataBricks makes Neon far less interesting to me. I simply don't trust such a large organisation that has previously had issues acquiring companies, to really care about what is pretty much the most important infrastructure I've got.

    There certainly is enough demand for a more "modern" postgresql, but pretty much all of the direct alternatives are straying far from its roots. Whether it be pricing, compatibility, source available etc.

    Back when I was looking at alternatives to postgres these were considered:

    1. AWS RDS: We were already on AWS RDS, but it is expensive, and has scaling and operations issues

    2. AWS Aurora: The one that ended up being recommended, solved some operations issues, but came with other niche downsides. Pretty much the same downsides as other wire compatible postgresql alternatives

    3. CockroachDB: Was very interesting, wire compatible, but had deeper compatibility issues, was open source at the time, it didn't fit with our tooling

    4. Neon: Was considered to be too immature at the time, but certainly interesting, looked to be able to solve most of our challenges, maybe except for some of the operations problems with postgresql, I didn't look deeper into it at the time

    5. Yugabyte: interesting technology, had some of the same compatibility issues, but less that the others, as they're also using the query engine from postgresql as far as I can tell.

    There are also various self hosting utilities for PostgreSQL I looked at, specifically CloudPG, but we didn't have the resources to maintain a stateful deployment of kubernetes and postgres ourselves. It would fulfill most of our requirements, but with extra maintenance burden, both for Kubernetes and PostgreSQL.

    Hosting PostgreSQL by itself, didn't have mature enough replication and operations features by itself at that point. It is steadily maturing, but as we'd got many databases manual upgrades and patches would be very time consuming, as PostgreSQL has some not so nice upgrade quirks. You basically have to unload and reload all data during major upgrades. Unless you use extensions and other services to circumvent this issue.

  • by lmc on 5/14/25, 10:38 AM

  • by davidgomes on 5/14/25, 11:36 AM

    Hey everyone, I'm an engineer at Neon and I wanted to share this FAQ which covers a lot of the questions that are being brought up in the comments here:

    https://neon.tech/databricks-faq

    We're really excited about this, and will try to respond to some of the questions people have here later.

  • by moonikakiss on 5/14/25, 8:16 PM

    This is really, really exciting. I see it as the “right” way OLTP and OLAP will converge.

    The OP and I built an HTAP system at SingleStore. A single database with one copy of data for both OLTP and OLAP workloads. HTAP never took off [0].

    What we learned was that OLTP (Postgres) should handle OLTP, while OLAP (data warehouses/lakes) should handle OLAP, with replication between them.

    Designing the 'up-to-date' replication between these systems is hard.... columnar stores just aren’t built for OLTP‑style writes, and can't keep up with your OLTP tables.

    Let’s see if Databricks and Neon can pull this off

    “give me up‑to‑date Postgres tables in Unity Catalog", no debezium --> kafka --> flink --> Iceberg. With Spark jobs in the back ensuring that Iceberg is an optimal state.

    https://www.mooncake.dev/blog/htap-is-dead

  • by Squarex on 5/14/25, 10:51 AM

    I’ve loved Neon and now I’m a little worried. Are there any alternatives?

  • by bittermandel on 5/14/25, 11:20 AM

    Big congratulations!

    I really do hope that their OSS strategy does not change due to this, as it's really friendly to people who want to learn their product and run smaller deployments. It's (intentionally or not) really hard to run at a big scale as the control plane is not open-source, which makes the model actually work.

  • by mehulashah on 5/14/25, 6:11 PM

    I am excited to see Databricks turn into the next Oracle. This type of acquisition was inevitable. The king is dead! Long live the king!

    And yes, congratulations to the Neon team! (Nikita is, after all, YC)

  • by orangechairs on 5/14/25, 8:24 PM

    How are Neon employees doing? Heard Neon laid off a few teams this week. That's fun. Anyone hear if their shares are worth anything in the acquisition?

  • by jenny91 on 5/14/25, 1:06 PM

    It's my understanding that Neon had some tech to basically "wake up" the DB when a request came out -- so you could "scale down to zero," if you will. I was hoping to explore this for small personal projects: I by far prefer Postgres and would love an isolated database per project.

    Is there an alternative for that? Scale-to-zero postgres, basically?

  • by jlengrand on 5/14/25, 1:41 PM

    Congrats folks at Neon! Been following the team and product since the very beginning. Well done, good DX and good education content too :).

    This seems like quite the pivot though

  • by netvarun on 5/14/25, 1:19 PM

    Does anyone have insight into Neon's financials - specifically their revenue, COGS, and gross margins? I'm trying to understand what made Databricks value them at $1B. Was it strong unit economics, rapid growth, or mostly strategic/tech value?

  • by mellosouls on 5/14/25, 12:27 PM

    Previous discussion a few days ago:

    https://news.ycombinator.com/item?id=43899016

    Databricks in talks to acquire startup Neon for about $1B (174 comments)

  • by foota on 5/14/25, 12:59 PM

    So... As someone who's joining databricks in a few weeks, what's with the hate in the comments?

  • by bootsmann on 5/14/25, 11:09 AM

    The Databricks vs. Snowflake bidding war is probably an insanely good time to be a database startup.

  • by BohuTANG on 5/15/25, 12:47 AM

    Neon (open-source alternative to Aurora) is 73.6% Rust. Databend (open-source Snowflake alternative) is even more Rust-heavy at 97.2%.

    Interesting trend - modern serverless databases choosing Rust for its memory safety, performance predictability. Makes sense for systems where reliability and efficiency are non-negotiable.

  • by anentropic on 5/14/25, 12:36 PM

    How do they know 80% of Neon databases are created by AI agents?

  • by amazingamazing on 5/14/25, 2:24 PM

    Not too familiar with Neon other than the basics - its premise is that you use S3 as bottomless storage for Postgres and it’s otherwise the same as standard Postgres right? And this is all open source? Why are people paying? Can’t you use a cloud provider and have them host this for you?

  • by xzhuang1984 on 5/15/25, 2:23 AM

    Congratulations to the Neon.

    I believe that future data platforms will adopt an all-in-one approach, offering OLTP, OLAP, as well as support for other hybrid workloads such as vector, graph, and time series. This will lower user costs and be more friendly to applications in the AI era.

  • by aynyc on 5/15/25, 11:28 AM

    I really like databricks at the beginning, Spark clusters magically appear whenever I needed them. No more thoughts were given on how to store the data, etc.. After a few years, I've grown, so did my skill set and my employer. Databricks simply couldn't grow with us at the rate that we needed. No, not because of scaling, but the toolings such as AI/ML, what the market is demanding us to do. Faster iterations and experiments, less cost.

    Databricks now reminds me of Oracle. Still a great product, but it's a melting delicious ice cream.

  • by dan_goosewin on 5/14/25, 2:22 PM

    > Neon is valued at $1B;

    Neon is still early‑stage and, AFAIK, not profitable. It’s a perfect snapshot of 2025: anything that’s (1) serverless, and (2) even vaguely AI‑adjacent is trading at a multiple nobody would have believed two years ago. Also supports my hypothesis that the next 12 months will be filled with cash acquisitions.

    > Databricks will ruin Neon;

    I certainly hope not. Focus on DX, friendly free tier, and community support is what made it special. If that vanishes behind Databricks’ enterprise guardrails, the goodwill will vanish with it.

  • by whinvik on 5/14/25, 9:07 PM

    I don't get this metric - 80% of databases are being created by AI agents. Is this because of tools like Lovable. Are they just creating databases when creating a website?

  • by zombot on 5/15/25, 10:51 AM

    When data bricks contain neon, do they glow in the dark?

  • by presentation on 5/14/25, 10:50 AM

    Guess this is the beginning of the end of a great service, not holding my breath. Sounds like from the WSJ article that they’ll just become some AI agent backend service for Replit, and from the previous conversation on HN that Databricks ruins and shutters their acquisitions. Congrats on the big payout for the employees, though.

  • by rbanffy on 5/14/25, 12:02 PM

    At first I thought it had something do to with arm64 SIMD instructions.

  • by gopi on 5/20/25, 5:38 PM

    Anyone considering Turso?

  • by anshumankmr on 5/14/25, 12:27 PM

    What happens to existing customers of Neon?

  • by crowcroft on 5/15/25, 2:42 PM

    Someone deeper into the Databricks world correct me if this sounds like nonsense, but after thinking about this more my theory is that this is a defensive move for Databricks.

    Smaller companies don't usually need Databricks until they grow and become larger with more complex needs, and enough data that queries start to take a long time to run.

    As bare metal gets so much faster the point where you hit scaling issues with a DB becomes further and further away.

    As this trend continues more companies might decide they don't need Databricks they just need a few Postgres replicas and nothing else.

    Neon is kind of like an insurance policy against this outcome.

  • by bradhe on 5/14/25, 12:56 PM

    Crazy how big the data ecosystem has grown. Congrats to the Neon team on a good outcome, but good luck integrating into DBX culture and surviving.

    I'm seeing a lot of DBX hate in this thread overall. I think it's warranted. At Tower[0], we're trying to provide a decent open solution. It stars with owning your own data, and Iceberg helps you break free.

    [0] - https://tower.dev

  • by barrrrald on 5/14/25, 1:48 PM

    congrats to Nikita and all the wonderful folks at Neon!

  • by joshstrange on 5/14/25, 12:48 PM

    I’m incredibly disappointed by this news. I really enjoyed Neon but I seriously doubt I’m going to like Databricks’ stewardship if it. And that’s if they even still care about catering to people like me and don’t jack the prices us.

    I guess it’s time to go back to the well of managed/serverless Postgres options…

  • by whobre on 5/14/25, 10:50 AM

    A VC funded company that has never been profitable spending a billion on another startup…