Live data from Hacker News

Databricks acquires Neon

databricks.com

221–230 of 234 posts

Re: Databricks acquires Neon

#221

Earlier quoted context omitted.

Yup. And OpenShift. And Red Hat for Linux. And SAP. And IBM. But you know what? Tiny group of people relative to the impact, revenue and competitors. If we needed skills we clicked “buy”, 100 consultants would arrive who are experts, sort it and we’d move on. Not scratching around looking for people who know what we use and needing to learn 50 different open source tools. Coming from a much looser universe I learned…

I've worked at a Swedish streaming company, we bought a filesystem from IBM called "GPFS" or something before it was renamed. Well we had shit performance, reliability and everything else that could be bad. It was running on FC switches recommended by IBM, config from IBM, everything from IBM and it was an absolute fucking joke, metadata timed out regularly and the solution was "deal with it". I think my superiors sh…

We only used MQ. Against my recommendation, but it was fine if imperfect, and a known entity to all concerned. Did not use that file system.

Re: Databricks acquires Neon

#222

Earlier quoted context omitted.

Not commoditising for enterprise. My last gig wouldn’t allow open source software or any company that might not be there in a decade, or which kept data anywhere but our own tenant. We’d look for the “call us” pricing rather than hate it, which I normally do. We added databricks and it was considered one of my top three achievements, because they don’t have to think about data platforms again, just focus on using it.…

> My last gig wouldn’t allow open source software or any company that might not be there in a decade I bet they had VMware all over the place.

Battered woman syndrome

Re: Databricks acquires Neon

#223
post #173

Earlier quoted context omitted.

With the push towards open table formats (Iceberg) from both Snowflake and Databricks, it's even harder to get your Postgres OLTP tables ready for OLAP. The problem isn't in the CDC / replication tools in the market. The problem is that columnar stores (especially Iceberg) are not designed for the write /upserts patterns of OLTP systems. They just can't keep up... This is a big problem we're hoping to solve at Moonca…

Is Iceberg involved in every read/write? I thought it was mostly metadata?

DataFile(parquet) is not enough for table with update/delete, (they are part of iceberg "metadata"). for CDC from OLTP use-cases, the pattern involves rapidly marking rows as deleted/ insert new rows and optimizing small files. This is required for minutes-latency replication.

And for second latency replication, it is more involving, you actually need to build layer on top of iceberg to track pk/ apply deletion.

Re: Databricks acquires Neon

#224

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.

What's the relationship to replit?

I misread the WSJ article, it was just some generic comment from Replit; but still, I am not very optimistic about this.

Re: Databricks acquires Neon

#225
post #153

Earlier quoted context omitted.

if Databricks just wanted a row DB they couldve done postgres themselves. paying this much for Neon i think is a sign that Neon has something special they want (which, knowing their marketing line, is "independently scalable storage and compute for postgres")

That sounds like AWS Aurora?

mashed w a lil bit of snowflake arch

Re: Databricks acquires Neon

#226
post #56

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

Welcome to Databricks! I've been an SA at Databricks for the past two years and love it here. The people you get to work with here are world-class and our customers legitimately love our product. I too am a little confused about comments in threads on HN about Databricks, they seriously don't reflect what I see internally and what my customers say. I don't think I'd be working here if they did.

Thank you, I'm excited!

Re: Databricks acquires Neon

#227
post #109
post #70

Earlier quoted context omitted.

Do you support http or websocket connections like https://github.com/neondatabase/serverless ? In my experience neon is ultra fast that way in serverless environments like 1-5ms per query with network roundtrip.

We have support for SQL over HTTP in Xata Lite: https://lite.xata.io/docs/sdk/sql/overview

Any plans for websockets? Neon supports transactions over them.

Re: Databricks acquires Neon

#228

Earlier quoted context omitted.

Profitability might not be as relevant as it used to be in M&A discussions, but it matters when you’re paying $1B. Valuations like this only make sense if there’s a clear path to significant strategic leverage or future cash flow.

No, it doesn't matter when you're paying $1B. Why would it? Tech companies don't care about profits. It's easy to become profitable - tech margins are obnoxiously high. They're bought and valued for their ability to scale and rapidly absorb market share.

Fair point. I submit that I'm probably overestimating how much profitability matters here.

I've been hearing that Neon is burning through cash pretty aggressively, which raised eyebrows for me. But you're right: high margins and scalability mean profits can be deferred.

Re: Databricks acquires Neon

#229

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.

Wow, go them! https://github.com/databendlabs/jepsen.meta#jepsenmetasrv

Re: Databricks acquires Neon

#230

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.

>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

It's already available and open source by the nice folks from MIT and they even wrote a book on it [1],[2].

You can use it to develop modern datahub for data engineering and analytics [3],[4].

[1] D4M: Dynamic Distributed Dimensional Data Model:

https://d4m.mit.edu/

[2] Mathematics of Big Data: Spreadsheets, Databases, Matrices, and Graphs:

https://mitpress.mit.edu/9780262038393/mathematics-of-big-da...

[3] Technical Report: Developing a Working Data Hub:

https://arxiv.org/abs/2004.00190

[4] Collaborative data analytics with DataHub:

https://dspace.mit.edu/handle/1721.1/100937

Post reply on HN