Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The road to ACID transactions in Cassandra 6

theconsensus.dev

Post reply on HN
Print view View original

21–26 of 26 posts

Re: The road to ACID transactions in Cassandra 6

#21

Post by ksec »

cyberpunk wrote: post #14
rajman187 wrote: post #9

Earlier quoted context omitted.

i'd say 99% of usecases will be served fine with Postgres, or a managed instance via AWS

We live in wildly different worlds, I think. How is postgres comparable to 6-12 nodes of cassandra? One really giant one with 200k worth of storage? Is there even a multi-master setup yet? every time i’ve looked it’s just around the corner. multigres from supabase seems promising, but im not touching it for at least a couple years… I’d love to use postgres, and have in various times in the past and love it (it never…

>multigres from supabase seems promising

I have high hopes for Neki from Planetscale but then again if you are not stuck on Postgres for whatever reason, Vitess with MySQL is about as battle tested as it gets.

Re: The road to ACID transactions in Cassandra 6

#22

Post by ali_alkhazraji »

heipei wrote: post #4
cyberpunk wrote: post #3

I'm sure for some workloads, cassandra is 'ideal' or at least was 10 years ago. What I can say though (as someone running thousands of cpus worth of cassandra at the moment); is that I deeply dislike this database. It's an operational nightmare, and I will not miss it even the slightest bit if it goes away forever. On the other hand, I'm sure glad to see a bit of life in cassandra dev, it seems to have been dormant f…

So what is the alternative? It took me a while to get around the data schema / modelling that a database like Cassandra imposed, but when it finally clicked it really clicked for me, so much so that I wish I could have the same performance footprint of consistent hashing / sharding with other databases. We are using ScyllaDB, but since they discontinued their Open Source version we're stuck on the last supported vers…

[flagged]

Re: The road to ACID transactions in Cassandra 6

#23

Post by javier2 »

kev009 wrote: post #7
javier2 wrote: post #6

Earlier quoted context omitted.

I also run a large-ish cassandra cluster, and I dont really disagree, but then what else? I would not recommend starting new projects with it either, but what else will you use?

Wasn't ScyllaDB designed to be a drop in? The idea of running a Java or Golang DB sounds like fresh hell to me.

its not a drop in. There is no reasonable way of replacing a huge existing cassandra cluster with scylladb. You have to transition as it was a new database.

Re: The road to ACID transactions in Cassandra 6

#24

Post by jjirsa »

cyberpunk wrote: post #3

I'm sure for some workloads, cassandra is 'ideal' or at least was 10 years ago. What I can say though (as someone running thousands of cpus worth of cassandra at the moment); is that I deeply dislike this database. It's an operational nightmare, and I will not miss it even the slightest bit if it goes away forever. On the other hand, I'm sure glad to see a bit of life in cassandra dev, it seems to have been dormant f…

Feels like a thread for me

I’ve run more Cassandra than anyone on the planet. Also more FoundationDB. And more Postgres than I can count. Likely 3 orders of magnitude more than you.

1. Any db at that scale requires a team. Thousands of cores is gonna be either paying saas or paying a team and I don’t care what the tech is. You’re gonna fuck up any db on the market letting your app eng run a thousand cores of Postgres or MySQL or couchbase or cockroach or tidb.

2. Cassandra at scale has a demonstrably better cost and availability slo than literally annything else I’ve ever tried to run, as long as you have a competent team. And I had a great team. But we had a great team because we understood that at million core scale it’s a core of the product and you invest in your core. But a good team of a dozen people can run a million cores at 6-8 nines, at lower cost per byte or cost per query than any db-aas you can buy online from any cloud vendor. I know this because we checked, and I’ve been ahead every time.

3. The db isnt fun to run. But it’s getting way better. If you think this is 2009, it’s not. The folks working on it in 2026 know what they’re doing and the last decade has made it measurably safer and easier.

Nothings free, but I’d bet my salary I can run damn near any company on Cassandra cheaper than any of your alternatives. Even all the vendors who keep selling against Cassandra. A competent team on Cassandra is going to beat your vendor product 90% of the time.

Re: The road to ACID transactions in Cassandra 6

#25

Post by cyberpunk »

jjirsa wrote: post #24
cyberpunk wrote: post #3

I'm sure for some workloads, cassandra is 'ideal' or at least was 10 years ago. What I can say though (as someone running thousands of cpus worth of cassandra at the moment); is that I deeply dislike this database. It's an operational nightmare, and I will not miss it even the slightest bit if it goes away forever. On the other hand, I'm sure glad to see a bit of life in cassandra dev, it seems to have been dormant f…

Feels like a thread for me I’ve run more Cassandra than anyone on the planet. Also more FoundationDB. And more Postgres than I can count. Likely 3 orders of magnitude more than you. 1. Any db at that scale requires a team. Thousands of cores is gonna be either paying saas or paying a team and I don’t care what the tech is. You’re gonna fuck up any db on the market letting your app eng run a thousand cores of Postgres…

What exactly is your point, besides the self aggrandising? None of this is news to anyone, but I'm sure we're all glad to hear you're so shit-hot at everything.

Re: The road to ACID transactions in Cassandra 6

#26

Post by cnlwsu »

andriy_koval wrote: post #19
heipei wrote: post #4

Earlier quoted context omitted.

So what is the alternative? It took me a while to get around the data schema / modelling that a database like Cassandra imposed, but when it finally clicked it really clicked for me, so much so that I wish I could have the same performance footprint of consistent hashing / sharding with other databases. We are using ScyllaDB, but since they discontinued their Open Source version we're stuck on the last supported vers…

> We are using ScyllaDB, but since they discontinued their Open Source version we're stuck on the last supported version Do you think you are missing anything by being on scylla oss?

Same issue we had with cockroach. The oss is lagging and you ultimately need to end up paying the company for support. its really just "kinda oss" in that you can look at source code from 2 years ago but to actually use it, might as well be oracle. If your fork it you are just gonna be in a hostile environment (unless you pay them)
Post reply on HN