5 ms·

You understand the point. It's a real point. Show me a modern relational database that can scale this predictably on the cloud with this level operability.

tiffanyh 4y ago
When you have to eliminate data relationships for it to scale, you no longer have a "relational" database.
- sroussey 4y ago
  You would be surprised then. Most SaaS companies can easily shard by customer. All the customer data stays together, relational and all. Cross-customer queries will be somewhat slower.
  - tiffanyh 4y ago
    Sure, but what you are describing is no longer a multi-tenant application/database. It's essentially a single-tenant deployment of your tech stack per customer. Which is not very cost effective.
    - deleted 4y ago
      [deleted]
    - staticassertion 4y ago
      I would still consider it a multi-tenant system. It's a single database to manage, which distributes your customers using their identity as a partitioning key.
    - sroussey 4y ago
      It’s multi tenant —- you have 10,000,000 customers with 1,000,000 each on 10 servers, for example. Or I don’t understand what you mean…
    - ithrow 4y ago
      No, a single database manages multiple customers but the customers are distributed among multiple databases.
hbrn 4y ago
A relational database without relations is an oxymoron. As folks pointed out, you also have to throw ACID away. So what's left of the original database, SQL-dialect? I bet that gets limited too. Look, I get it, you have to sell your product. Some folks want semi-infinitely scalable storage, and they don't understand that the only way to achieve it is turning their DB into a key-value store. As a side effect they would have to rewrite their whole application from scratch, but they would only realize it after they get vendor locked in. You can advertise your solution as MySQL-compatible. And I can claim that it's dishonest.
- mattlord 4y ago
  > A relational database without relations is an oxymoron. OK. You're the only one talking to this straw man though. :-) Every Vitess user that I'm aware of has a pretty typical 2NF/3NF schema design. A small sampling of them being listed here: https://vitess.io https://vitess.io You setup your data distribution/partitioning/sharding scheme so that you have data locality for 99.9999+% of your queries -- meaning that the query executes against a data subset that lives on a single shard/node (e.g. sharding by customer_id) -- and you live with the performance hit and consistency tradeoffs for those very rare cases that cross shard queries cannot be avoided (Vitess does support this). You should do this even if the solution you're using claims to have distributed SQL with ACID and MVCC guarantees/properties. There's no magic that improves the speed of light and removes other resource constraints. In practice most people say they want perfect security/consistency/<name your desired property here> but then realize that the costs (perf, resources, $$, etc) are simply so high that it is not practical for their business/use case. I know MySQL fairly well (I started working at MySQL, AB in 2003) and you can certainly claim that "MySQL-compatible" is dishonest but I would offer a counter claim that either you don't know this space very well or you're not operating in good faith here.
  - hbrn 4y ago
    To be fair, I skimmed through your docs and did misread them initially: I thought you don't allow foreign keys, but you actually don't allow foreign key constraints. If you are still allowing JOINs within a shard, then I need to apologize.

tiffanyh 4y ago

When you have to eliminate data relationships for it to scale, you no longer have a "relational" database.

sroussey 4y ago
You would be surprised then. Most SaaS companies can easily shard by customer. All the customer data stays together, relational and all. Cross-customer queries will be somewhat slower.
- tiffanyh 4y ago
  Sure, but what you are describing is no longer a multi-tenant application/database. It's essentially a single-tenant deployment of your tech stack per customer. Which is not very cost effective.
  - deleted 4y ago
    [deleted]
  - staticassertion 4y ago
    I would still consider it a multi-tenant system. It's a single database to manage, which distributes your customers using their identity as a partitioning key.
  - sroussey 4y ago
    It’s multi tenant —- you have 10,000,000 customers with 1,000,000 each on 10 servers, for example. Or I don’t understand what you mean…
  - ithrow 4y ago
    No, a single database manages multiple customers but the customers are distributed among multiple databases.

hbrn 4y ago

A relational database without relations is an oxymoron. As folks pointed out, you also have to throw ACID away. So what's left of the original database, SQL-dialect? I bet that gets limited too. Look, I get it, you have to sell your product. Some folks want semi-infinitely scalable storage, and they don't understand that the only way to achieve it is turning their DB into a key-value store. As a side effect they would have to rewrite their whole application from scratch, but they would only realize it after they get vendor locked in. You can advertise your solution as MySQL-compatible. And I can claim that it's dishonest.

mattlord 4y ago
> A relational database without relations is an oxymoron. OK. You're the only one talking to this straw man though. :-) Every Vitess user that I'm aware of has a pretty typical 2NF/3NF schema design. A small sampling of them being listed here: https://vitess.io https://vitess.io You setup your data distribution/partitioning/sharding scheme so that you have data locality for 99.9999+% of your queries -- meaning that the query executes against a data subset that lives on a single shard/node (e.g. sharding by customer_id) -- and you live with the performance hit and consistency tradeoffs for those very rare cases that cross shard queries cannot be avoided (Vitess does support this). You should do this even if the solution you're using claims to have distributed SQL with ACID and MVCC guarantees/properties. There's no magic that improves the speed of light and removes other resource constraints. In practice most people say they want perfect security/consistency/<name your desired property here> but then realize that the costs (perf, resources, $$, etc) are simply so high that it is not practical for their business/use case. I know MySQL fairly well (I started working at MySQL, AB in 2003) and you can certainly claim that "MySQL-compatible" is dishonest but I would offer a counter claim that either you don't know this space very well or you're not operating in good faith here.
- hbrn 4y ago
  To be fair, I skimmed through your docs and did misread them initially: I thought you don't allow foreign keys, but you actually don't allow foreign key constraints. If you are still allowing JOINs within a shard, then I need to apologize.