3 ms·

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

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.

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.