3 ms·

yeah but I don't think that we can just trust that when people say this. They are invested into these single node databases for 10+ years probably. They are not

yeah but I don't think that we can just trust that when people say this. They are invested into these single node databases for 10+ years probably. They are not going to tell you: Hey yeah, if you architect your app differently you could have x10 the performance.. but don't because it's a bit annoying when you query data. I mean is that being objective? Lots of people are not okay with the performance of mysql/postgres, that's the whole point of solutions like crdb/tidb/singlestore/vitess/yugabyte/citus and so many others. To tell someone that they should start with mysql or postgres is the equivalent of telling them that they'll have to migrate in the future and relearn a whole bunch of stuff about the operations, like backup etc. I don't really like the feeling of choosing a technology with the mindset that I'll have a lot of problems when there is a performance problem and at some point the pain will be so great that I'll have to switch to vitess.

richieartoul 3y ago
It’s really not just about annoyance it’s about correctness and speed of iteration. Many apps that can be built trivially in a couple SQL queries cannot be implemented correctly in Scylla without reinventing half of tidb/vitess/etc. On top of that, it’s very hard to hire and pay the engineers who are capable of doing that in the first place. Finally, even if you manage to do it, your competitors will have shipped 100x more functionality than you in that time. That’s why people use these systems and why so many very smart people spend so much time trying to make them better
- Nathanba 3y ago
  Well I do everything myself, I think what you said is mostly true only from the perspective of people who use orms and then everything works initially sure. But then are you really in control of your data and do you really know what's going on? I can only speak from a .net perspective now but the popular ORMs are all extremely slow, so with some research you end up using dapper. But then you end up basically writing SQL manually because that's just how it is. It wouldn't be any different for many languages, like Rust. Essentially I think unless you use java+hibernate or some other extremely common combination, you'll end up writing SQL yourself and then it's pretty painful anyway because you have a second textual DSL embedded into your other code with its own datatypes that you constantly have to map to the language's datatypes and vice versa. So iteration wise it doesnt even seem to be about mysql vs scylladb, it is about orm vs. no orm. And regarding correctness and iteration speed.. yes sure but it's easy to say that you are correct when you only run on a single node. The reason why those distributed solutions are less correct is because it's harder to be correct. For example in vitess you end up having to do a bunch of manual work with their sequences for every table. In scylladb afaik you just trust that the timeuuids are unique or you do the same and pregenerate bigints into a table. My point is: To say that mysql/postgres are safer because they are correct and you can iterate faster is only true if you go down a very narrow path with your orm and you stay on a single node. You are essentially postponing all the pain. At some point you'll stop using the orm and write your own, at some point you'll stop using the single node.
  - richieartoul 3y ago
    I think it’s the last paragraph I’m really disagreeing with. Many many application will do just fine with a single Postgres. If that is not enough even on a big box, they can scale out to a large master system like aurora. If that is not enough, it’s much easier to try and scale with something like Vitess or Cockroach that offers a lot more consistency and correctness out of the box. Scylla is great for specific workloads, but it’s a niche tool that makes sense for specific high volume workloads but I wouldn’t recommend it as a general purpose application development database. It will slow you down a lot and a lot of really simple features will be hard to implement. Also I’m not talking about ORMs. Writing SQL by hand in your application is 10-100x more productive for feature development than using something like Scyllas APIs directly IMO.
    - Nathanba 3y ago
      CQL to me is just another SQL dialect, databases all have different, incompatible dialects. And on top of that, it's not like SQL is a highly productive programming language anyway, it's a pretty hard to use language for anything that's even slightly more complicated. I don't really see where this x10-x100 more productiveness would come from compared to scylla APIs which are just another form of SQL dialect so it isn't that different. Sure I can't write e.g (recursive)CTEs or repeating events in Scylladb but then: do I really want them anyway? wouldn't it be better anyway if I write everything as a set of simple queries? Wouldn't it be better anyway if instead of an event on an interval in SQL, I'd just run a simple SQL query in a background thread from my application on an interval?
      - Mike_12345 3y ago
        > CQL to me is just another SQL dialect SQL is for relational databases. That's a different paradigm to CQL. The similarity is superficial. CQL is not a dialect of SQL. Not even close.
Aeolun 3y ago
People saying the performance of Postgres is not adequate is my red flag for them not knowing what they’re doing. Of course, sometimes they do have actual performance issues, but 99 out of 100 times they just don’t know what an index is.

richieartoul 3y ago

It’s really not just about annoyance it’s about correctness and speed of iteration. Many apps that can be built trivially in a couple SQL queries cannot be implemented correctly in Scylla without reinventing half of tidb/vitess/etc. On top of that, it’s very hard to hire and pay the engineers who are capable of doing that in the first place. Finally, even if you manage to do it, your competitors will have shipped 100x more functionality than you in that time. That’s why people use these systems and why so many very smart people spend so much time trying to make them better

Nathanba 3y ago
Well I do everything myself, I think what you said is mostly true only from the perspective of people who use orms and then everything works initially sure. But then are you really in control of your data and do you really know what's going on? I can only speak from a .net perspective now but the popular ORMs are all extremely slow, so with some research you end up using dapper. But then you end up basically writing SQL manually because that's just how it is. It wouldn't be any different for many languages, like Rust. Essentially I think unless you use java+hibernate or some other extremely common combination, you'll end up writing SQL yourself and then it's pretty painful anyway because you have a second textual DSL embedded into your other code with its own datatypes that you constantly have to map to the language's datatypes and vice versa. So iteration wise it doesnt even seem to be about mysql vs scylladb, it is about orm vs. no orm. And regarding correctness and iteration speed.. yes sure but it's easy to say that you are correct when you only run on a single node. The reason why those distributed solutions are less correct is because it's harder to be correct. For example in vitess you end up having to do a bunch of manual work with their sequences for every table. In scylladb afaik you just trust that the timeuuids are unique or you do the same and pregenerate bigints into a table. My point is: To say that mysql/postgres are safer because they are correct and you can iterate faster is only true if you go down a very narrow path with your orm and you stay on a single node. You are essentially postponing all the pain. At some point you'll stop using the orm and write your own, at some point you'll stop using the single node.
- richieartoul 3y ago
  I think it’s the last paragraph I’m really disagreeing with. Many many application will do just fine with a single Postgres. If that is not enough even on a big box, they can scale out to a large master system like aurora. If that is not enough, it’s much easier to try and scale with something like Vitess or Cockroach that offers a lot more consistency and correctness out of the box. Scylla is great for specific workloads, but it’s a niche tool that makes sense for specific high volume workloads but I wouldn’t recommend it as a general purpose application development database. It will slow you down a lot and a lot of really simple features will be hard to implement. Also I’m not talking about ORMs. Writing SQL by hand in your application is 10-100x more productive for feature development than using something like Scyllas APIs directly IMO.
  - Nathanba 3y ago
    CQL to me is just another SQL dialect, databases all have different, incompatible dialects. And on top of that, it's not like SQL is a highly productive programming language anyway, it's a pretty hard to use language for anything that's even slightly more complicated. I don't really see where this x10-x100 more productiveness would come from compared to scylla APIs which are just another form of SQL dialect so it isn't that different. Sure I can't write e.g (recursive)CTEs or repeating events in Scylladb but then: do I really want them anyway? wouldn't it be better anyway if I write everything as a set of simple queries? Wouldn't it be better anyway if instead of an event on an interval in SQL, I'd just run a simple SQL query in a background thread from my application on an interval?
    - Mike_12345 3y ago
      > CQL to me is just another SQL dialect SQL is for relational databases. That's a different paradigm to CQL. The similarity is superficial. CQL is not a dialect of SQL. Not even close.

Aeolun 3y ago

People saying the performance of Postgres is not adequate is my red flag for them not knowing what they’re doing. Of course, sometimes they do have actual performance issues, but 99 out of 100 times they just don’t know what an index is.