19 ms·

Why don’t more companies / startups choose ScyllaDB rather than Postgres or MySQL? ScyllaDB is a C++ version of Cassandra so it looks like speed and scalabilit

Why don’t more companies / startups choose ScyllaDB rather than Postgres or MySQL? ScyllaDB is a C++ version of Cassandra so it looks like speed and scalability is a complete advantage over the Java based Cassandra and Discord is using ScyllaDB at scale too.

olivermuty 3y ago
Because I (we) want rigid schemas with transaction wrapped DDL migrations more than I want blazing speed at Discords scale.
- michaelmior 3y ago
  You can have a rigid schema with Cassandra/ScyllaDB. Transactions are a whole other thing though for sure.
- riku_iki 3y ago
  Plus complex queries with rich capabilities
joeatwork 3y ago
There are a bunch of common workloads (including i’m guessing HN itself) where the trade offs for distributed databases make them a lot harder to use well, or where distributed databases don’t make sense.
- whynotmaybe 3y ago
  Government agencies I've worked usually build an app and put it in production without very few evolutions for 15+ years. Data is the most important stuff for them and being able to read it is therefore very important. A nosql DB structure can usually only be read by the code that goes with it and if nobody understands the code you're doomed. In 2017, I had to extract data from an app from 1994. The app was built with a language that wasn't widely used at the time and had disappeared today. It disappeared before all the software companies put their doc on the internet. You can't run it on anything older than windows2k. There was only one guy in Montréal that knew how to code and run that thing. As the DB engine was relational with a tool like sqlplus, I was able to extract all the data and we rebuilt the app based on the structure we found in the database. If you want to do that with Nosql, you must maintain a separate documentation that explains your structure... And we all now how dev like documentation.
erulabs 3y ago
Because Postgres and MySQL are more familiar and by the time they're falling over, you have raised 80M and can afford to hire folks like me who's entire job is pestering developers to stop reading-after-writing, to stop forcing queries to the primary (just incase there's lag!), to stop "select id from table" -> "select data_I_want from other_table where ID IN (list-of-a-million-ids"), to beg AWS for early access to the fastest possible machines, to systematically destroy the custom ORM you built during the first 5 years of the company, before you had customers. Scylla/Cassandra is exactly the database you want when you're serving the entire planet. Postgres is exactly the database you want when you're desperately searching for product market-fit and just need things to work and code to get written. Turns out it's much better to start simple and face scaling problems maybe than start complex and face scaling problems maybe.
- gajus 3y ago
  What's wrong with "select id from table"? (presumably "where" skipped for brevity of the example)
  - pritambaral 3y ago
    I read it as "`where` skipped at code time because the table is never going to be too large".
  - CBLT 3y ago
    It looks like what they're describing is implementing database joins in the application: 2 network round trips, first one for ids from a table and the second to get values from another table with foreign keys corresponding to the ids.
    - WanderPanda 3y ago
      Isn‘t implementing joins in the application what microservices are all about?
      - _jal 3y ago
nzach 3y ago
There are a lot of factors at play. But I think the biggest one is lack of expertise in the community. For postgress isn't that hard to hire a professional with 10 years of real world experience. Besides that you need to keep in mind that scylla isn't a silver bullet. There are some workloads that it can't handle very well. Where I work we tried to use it in workload with high read and writes and it had trouble to keep up. In the end we switched back to postgres + redis because it was cheaper.
- esafak 3y ago
  Can you be more specific? I am surprised Scylla got overwhelmed; it powers Discord.
bastawhiz 3y ago
There are lots of tradeoffs when choosing Cassandra: 1. If you delete data, tombstones are a problem that nobody wants to have to think about. 2. Denormalizing data instead of joining isn't always practical or feasible. 3. If you're not dealing with large amounts of data, Postgres and MySQL are just easier. There's less headache and it's easier to build against them. 4. One of the big advertised strengths of Cassandra is handling high write volume. Many applications have relatively few writes and large amounts of reads.
- pmcf 3y ago
  Fast writes and slow reads was true in 2012. The project has been busy since.
  - bastawhiz 3y ago
    Fast reads are commonplace. Having fast writes for a workload without an especially high volume of writes is not selling anyone on a database.
- swingingFlyFish 3y ago
  Unless it's a commenting system ;)
pid-1 3y ago
Why would use a database that is closely linked to a VC backed startup when PostgreSQL works fine you?
nemothekid 3y ago
>choose ScyllaDB rather than Postgres or MySQL? I've worked with a large Cassandra cluster at a pervious job, was involved with a Scylla deployment, and have a lot of experience with the architecture and operations of both databases. I wouldn't consider Cassandra/Scylla a replacement for Postgres/MySQL unless you have a very specific problem, namely you need a highly available architecture that must sustain a high write throughput. Plenty of companies have this problem and Scylla is a great product, but choosing it when you are just starting out, or if you are unsure you need it will hurt. You lose a lot of flexibility, and if you model your data incorrectly or you need it in a way you didn't foresee most of the advantages of Cassandra become disadvantages.
dangoodmanUT 3y ago
Transactions mean you can build faster as you don't have to write a bunch of code to achieve those features
pmcf 3y ago
That speed thing is a nice bit of marketing from Scylla but not really true in the real world.
jskrablin 3y ago
Because SQL and relational data. They're (MySQL and Pg) a lot more familiar to setup and maintain. There's a lot of managed services offering for the usual SQL databases. Cassandra/Scylla come with a lot of limitations when compared to typical SQL DB. They were developed for specific use cases and aren't at all comparable to SQL DBs. Both are completely different beast compared to standard SQL DBs.
jeffchao 3y ago
Probably the ecosystem and documentation. PaaS like Render, Fly, and even Heroku from back in the day offer addons/plugins/whatever that make the obvious choice out to be Postgres/MySQL. Then there's other tooling such as migration and various ORM adapters. Then there's a wealth of blogs, stack overflow q&a's, etc. And then Postgres/MySQL gets you quite far. Start with a single node -> scale the node -> add read replicas -> shard. Then, sharding becomes painful? Start looking at other data stores, remodeling your data, or eventing, etc.
dacryn 3y ago
ecosystem integration Postgres is super well supported, basically every tool out there has a connector to postgres, and most people have familiarity If I am honest, I never even bother researching alternatives, I always go with postgres out of habit. I know it, and it has never let me down
wbsun 3y ago
Is there any benchmark data to show the difference between no-sql DBs written in different languages when it comes to a real distributed system rather than just a handful of machines?

olivermuty 3y ago

Because I (we) want rigid schemas with transaction wrapped DDL migrations more than I want blazing speed at Discords scale.

michaelmior 3y ago
You can have a rigid schema with Cassandra/ScyllaDB. Transactions are a whole other thing though for sure.
riku_iki 3y ago
Plus complex queries with rich capabilities

joeatwork 3y ago

There are a bunch of common workloads (including i’m guessing HN itself) where the trade offs for distributed databases make them a lot harder to use well, or where distributed databases don’t make sense.

whynotmaybe 3y ago
Government agencies I've worked usually build an app and put it in production without very few evolutions for 15+ years. Data is the most important stuff for them and being able to read it is therefore very important. A nosql DB structure can usually only be read by the code that goes with it and if nobody understands the code you're doomed. In 2017, I had to extract data from an app from 1994. The app was built with a language that wasn't widely used at the time and had disappeared today. It disappeared before all the software companies put their doc on the internet. You can't run it on anything older than windows2k. There was only one guy in Montréal that knew how to code and run that thing. As the DB engine was relational with a tool like sqlplus, I was able to extract all the data and we rebuilt the app based on the structure we found in the database. If you want to do that with Nosql, you must maintain a separate documentation that explains your structure... And we all now how dev like documentation.

erulabs 3y ago

Because Postgres and MySQL are more familiar and by the time they're falling over, you have raised 80M and can afford to hire folks like me who's entire job is pestering developers to stop reading-after-writing, to stop forcing queries to the primary (just incase there's lag!), to stop "select id from table" -> "select data_I_want from other_table where ID IN (list-of-a-million-ids"), to beg AWS for early access to the fastest possible machines, to systematically destroy the custom ORM you built during the first 5 years of the company, before you had customers. Scylla/Cassandra is exactly the database you want when you're serving the entire planet. Postgres is exactly the database you want when you're desperately searching for product market-fit and just need things to work and code to get written. Turns out it's much better to start simple and face scaling problems maybe than start complex and face scaling problems maybe.

gajus 3y ago
What's wrong with "select id from table"? (presumably "where" skipped for brevity of the example)
- pritambaral 3y ago
  I read it as "`where` skipped at code time because the table is never going to be too large".
- CBLT 3y ago
  It looks like what they're describing is implementing database joins in the application: 2 network round trips, first one for ids from a table and the second to get values from another table with foreign keys corresponding to the ids.
  - WanderPanda 3y ago
    Isn‘t implementing joins in the application what microservices are all about?
    - _jal 3y ago

nzach 3y ago

There are a lot of factors at play. But I think the biggest one is lack of expertise in the community. For postgress isn't that hard to hire a professional with 10 years of real world experience. Besides that you need to keep in mind that scylla isn't a silver bullet. There are some workloads that it can't handle very well. Where I work we tried to use it in workload with high read and writes and it had trouble to keep up. In the end we switched back to postgres + redis because it was cheaper.

esafak 3y ago
Can you be more specific? I am surprised Scylla got overwhelmed; it powers Discord.

bastawhiz 3y ago

There are lots of tradeoffs when choosing Cassandra: 1. If you delete data, tombstones are a problem that nobody wants to have to think about. 2. Denormalizing data instead of joining isn't always practical or feasible. 3. If you're not dealing with large amounts of data, Postgres and MySQL are just easier. There's less headache and it's easier to build against them. 4. One of the big advertised strengths of Cassandra is handling high write volume. Many applications have relatively few writes and large amounts of reads.

pmcf 3y ago
Fast writes and slow reads was true in 2012. The project has been busy since.
- bastawhiz 3y ago
  Fast reads are commonplace. Having fast writes for a workload without an especially high volume of writes is not selling anyone on a database.
swingingFlyFish 3y ago
Unless it's a commenting system ;)

pid-1 3y ago

Why would use a database that is closely linked to a VC backed startup when PostgreSQL works fine you?

nemothekid 3y ago

>choose ScyllaDB rather than Postgres or MySQL? I've worked with a large Cassandra cluster at a pervious job, was involved with a Scylla deployment, and have a lot of experience with the architecture and operations of both databases. I wouldn't consider Cassandra/Scylla a replacement for Postgres/MySQL unless you have a very specific problem, namely you need a highly available architecture that must sustain a high write throughput. Plenty of companies have this problem and Scylla is a great product, but choosing it when you are just starting out, or if you are unsure you need it will hurt. You lose a lot of flexibility, and if you model your data incorrectly or you need it in a way you didn't foresee most of the advantages of Cassandra become disadvantages.

dangoodmanUT 3y ago

Transactions mean you can build faster as you don't have to write a bunch of code to achieve those features

pmcf 3y ago

That speed thing is a nice bit of marketing from Scylla but not really true in the real world.

jskrablin 3y ago

Because SQL and relational data. They're (MySQL and Pg) a lot more familiar to setup and maintain. There's a lot of managed services offering for the usual SQL databases. Cassandra/Scylla come with a lot of limitations when compared to typical SQL DB. They were developed for specific use cases and aren't at all comparable to SQL DBs. Both are completely different beast compared to standard SQL DBs.

jeffchao 3y ago

Probably the ecosystem and documentation. PaaS like Render, Fly, and even Heroku from back in the day offer addons/plugins/whatever that make the obvious choice out to be Postgres/MySQL. Then there's other tooling such as migration and various ORM adapters. Then there's a wealth of blogs, stack overflow q&a's, etc. And then Postgres/MySQL gets you quite far. Start with a single node -> scale the node -> add read replicas -> shard. Then, sharding becomes painful? Start looking at other data stores, remodeling your data, or eventing, etc.

dacryn 3y ago

ecosystem integration Postgres is super well supported, basically every tool out there has a connector to postgres, and most people have familiarity If I am honest, I never even bother researching alternatives, I always go with postgres out of habit. I know it, and it has never let me down

wbsun 3y ago

Is there any benchmark data to show the difference between no-sql DBs written in different languages when it comes to a real distributed system rather than just a handful of machines?