jjirsa

Waymo is now completing 450,000 weekly driverless rides across six cities, with a peer-reviewed study showing statistically significantly lower crash rates than human drivers across 56.7 million rider-only miles. When Waymo’s vehicles were caught passing school buses, the company filed a voluntary recall within weeks. Tesla, on the other hand, is now on its second deadline extension just to tell NHTSA about FSD’s traffic violations.

That, in itself, is saying more than anything else

Congrats datastax folks. Happy for you.

Youre not far off, just use your original sentence and acknowledge that Scylla isn’t the OSS here, its the company that came in, forked a volunteer driven project, and tried to pretend its theirs:

Or more often companies with money come to fork an open source project from the developer, and continue pretending it's their own now.

Copycat is a bit of a stretch here imho, considering it's in different language, and even the general architecture. But I agree they are very compatible on the protocol level, which they used as an advantage as people don't need to rewrite their code when they migrate

It's not a stretch. They literally copied the java code and re-implemented it class-by-class with Seastar/c++.

It's literally in the ORIGIN file in their repo: https://github.com/scylladb/scylladb/blob/dc375b8cd3e8c7e85d...

I would say it's opposite. No one contributes to open source and the developers have to make money on the side to work on the project

You missed the important part of his sentence:

All those open source copycat projects, using open source to get exposure then switching

The original open source here was Cassandra. Scylla exists to pick off that market share. They launch with a free license, pull customers, then swap license. The actual adoption of Scylla would have been a fraction had it been released under this license to start, which everyone understands.

Or more often companies with money come to fork an open source project from the developer, and continue pretending it's their own now

It had already been AGPL, so it's not like they're protecting against competition. They already had a license that avoided the forking problem. This isn't protection against AWS (keyspaces likely has more OSS cassandra code in the protocol tier than it has Scylla code, if it has either). It's protection against free consumption.

Remarkable to me that ctrl-f, "Sourceforge" had 3 hits on this page. Would have expected a dozen.

Some companies have both massive files and a massive number of files

I do wish they just contributed to nickel or something else though rather than doing their NIH as usual.

They’re contributing to a ton of OSS that’s NIH:

https://opensource.apple.com/projects/

K8s, spark, cassandra, netty, zookeeper, solr, containerd

Yes! Congrats Phil!

Regrettably the folks who have been using it for years aren’t going to be give a lot of specifics, but generation of k8s yaml / jsonnet in particular was exceptionally common. One example from the other thread:

My team migrated several kloc k8s configuration to pkl with great success. Internally we used to write alert definitions in pkl and it would generate configuration for 2 different monitoring tools, a pretty static documentation site and link it all together nicely.

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

Congrats Apple folks who worked on this, I know it’s been a long time coming

Cassandra’s jepsen is over 10 years old now.

That database spent 3-4 years primarily focused on correctness from 2018-2022.

The industry moves fast, our memories are slow. But there are millions of instances of cassandra in production across most of the fortune 500, and half of this thread has never heard of RavenDB

It’s disappointing to me that the technologist desire to experiment with new DBs continually puts naive customers at correctness and durability risk they don’t (won’t) understand.

Apple's underlying economics haven't changed, so they have not had any reason to over-hire in the first place.

The bloomberg article has a visual showing revenue-per-employee going up from 1.17M/employee (2017-2019) to 2.51M/employee (2020-2022), so ... some of the underlying economics changed somehow?

Tell me you’ve never run infrastructure at scale without telling me you’ve never run infrastructure at scale.

Just wanted to say thanks for understanding how hard this is.

It's a fun sub-thread to read.

As I mentioned elsewhere, I'll see if I can get permission to talk publicly about the actual numbers.

I'll see if we can get permission to discuss this publicly.

Cassandra is very good when all of these are true:

- You're willing to give up some common SQL-isms for leaderless, multi-dc, high-availability

- You're going to grow to need more than one machine taking writes - if you can fit on one normal commodity machine, just use something designed for one machine. Cassandra sacrifices a lot to scale to ~thousand-machines-per-cluster, so if you can use one machine, don't bother with Cassandra.

- You can model your data in a way that does SELECTs without JOINs, and always uses AT LEAST the partition key in the WHERE clause. Denormalizing and duplicating your data is PROBABLY ok.

- You're willing to run Java (so you understand that you may need to tune the JVM eventually), and you're willing to learn about data modeling before you just start writing code

If all of that is true, Cassandra starts being interesting.

I think Cassandra - certainly inter alia - simply sits at a level of complexity which is beyond the comprehension of any one human being

I think there are a handful of humans that actually get it. But it is a true handful, not more than 5.

The cardinal rule of databases: http://www.dbms2.com/2013/03/18/dbms-development-marklogic-h...

Ignoring that leads to long postmortems about how your embedded db failed in a way you didn’t expect: https://blog.roblox.com/2022/01/roblox-return-to-service-10-...

SQLite is good

Rocksdb is good

You don’t need pure go.

Targeting for home invasion

Targeting for extortion

Targeting in general

The “extraordinarily difficult to do very well” part gets ignored here by most people

DocuSign’s feature list is huge. It’s not just overlaying a signature on a doc. It’s a massive and complex app that most people will ignore or trivialize, but that shit just works.

Mark all the signature locations?

Multi-user?

Chained dependencies?

Recording and redownloading later?

SSO

Audit / identification

Salesforce integration?

Contract generation?

Orange site minimizing huge successful company because they care about one feature seems super on brand.

I don’t think anyone avoiding talking about single threaded bottlenecks. The main one that matters is on sstable streaming during bootstrap, and the zero copy streaming was directly to address that. There’s not really any single threaded pieces in cassandra that matter beyond that? If anything the opposite is true - thread pools everywhere leading to context switching and data copying for no reason.

On a deeper note, it probably says something about the user base that people who don’t run it in prod think the perf is really bad and yet there are very few people submitting perf improvement patches. Maybe most of the power users aren’t that worried about perf because they either know how to tune a JVM or they happen to size their clusters based on bytes on disk?

Your options for scylla are AGPL or pay scylla. Nobody risks AGPL in prod so people running it are probably paying scylla.

Modern Cassandra is more like Dict[SortedList[Row]], where the row is basically a SQL row just like you’d expect in any SQL database

Something something bigtable

The "reduced latencies" really reduces down to performance, where tps was a first order proxy for performance.

The ease of maintenance, similarly, is sold as easier due to reduced node count, which is perhaps an extension of performance but probably misunderstands (or ignores) that most people running large cassandra clusters have tooling that parallelizes most maintenance anyway, so the reduction in effort is sorta not that important in real life (if anything, having more machines gives you better blast radius behavior, consolidation onto fewer exposes you to larger percentages of loss/failure when there's inevitably a problem with the fewer, larger machines).

The real comparison, though, is missing in that link, because the real comparison is not performance. It's license. Nobody is running AGPL in prod unless they have zero IP worth protecting, so it's ultimately comparing OSS to proprietary.

(And similar disclosure: cassandra committer)

SQL-like query pattern on top of bigtable-like distribution.

e.g. you're willing to model your reads such that you dont need joins, and your sorting/scanning is based on the idea that you cluster data together, sorted in order you'll read it, into something called a "partition", which is how data is found within very large clusters.

then asking the machine for a whole bucketful of data, which should be a superset of what you're actually looking for. For something like a user's transactions you'll want to have basically everything there at once, so loading the "order history" page for the past month might be a single query that just returns a report: no joins at all, very fast, super scalable.

Not really a superset, cassandra (and scylla, and bigtable, all of which are basically copying bigtable's model) each try very hard not to read any extra data at all, and can often return approximately the exact data requested, modulo serialization data which is usually fitting in ~compression chunk size (64k) + checksum.

If you're using Cassandra and you're also not a fool, it's probably because you actually need a lot of scale

Cassandra also gives you very literally the most control over CAP tradeoffs of any database in the industry.

If you have 100 machines per DC in each of 10 dcs, what happens when one machine is offline? one rack? one dc? 2 dcs separated from 8? 6 dcs separated from 4? There's no single answer in cassandra (depends on replication factor, consistency of writes, consistency of reads, all of which are tunable, with 2 of those being tunable PER QUERY), the CAP tradeoffs are yours and yours alone. That flexibility is powerful for power users (it's also confusing for novices, which is unfortunate).

But to your first point, yes, the point is scale. The lack of opinions and deliberate functionality are designed to enable it to scale to thousands of hosts, potentially petabytes of data, trivially accessible in a single SQL-like CQL query, with realistic read latency < 1ms mean/avg and < 5ms p99 for a tuned workload where you know what you're doing. A lot of users will never need a database that can do a million reads per second across a thousand machines reaching p50 1ms on 2 petabytes of data, but Cassandra can do that, and you don't have to build a whole sharding layer on top of mysql/postgres/redis or even install Scylla to get there.

Vectorized/RedPanda for Kafka compatible service, at least.

RedPanda seems to be a better starting point to be honest - a lot of the market share for Cassandra doesn't actually need the extra tps of Scylla. Some customers do, but many many many do not.