3 ms·

> there are LOTS of people out there who think creating a new logical database for every new customer is a good idea, resulting in 2000+ databases on a system w

> there are LOTS of people out there who think creating a new logical database for every new customer is a good idea, resulting in 2000+ databases on a system when there should be 4. I'm genuinely curious as to why you feel this way?

beachstartup 11y ago
see? LOTS.
bpchaps 11y ago
An ungodly amount of reasons. The ability to manage that many, for one. Those poor devops folk who have to deal with that. On a more technical side as an example, the number of open files can only be so high. You really start to hit the limit when you do things like that, which is when the most interesting kinds application crashes happen. "Just increase the file count." results in "Our report shows that an OldServer did not include a necessary open file limit config change. Engineer #582 has been fired."
- leesalminen 11y ago
  CLI tooling has solved a lot of the problems that arise from many. Scripts for migration, host transfer, creation and deletion took some time to build out, but do work fine. I suppose we are lucky to have a very consistent workload per logical database. This allowed us to calculate our costs ahead of time. We found that we could keep DB costs at ~$1/customer/month. For a B2B SaaS product we were satisfied with that cost.
joncampbelldev 11y ago
My personal preference for a single multi-tenanted schema as opposed to 2000+ schemas is: Unless you require per customer customisations (which is a fast way to ensure you have an upper limit on the number of customers you can support) there is no need to duplicate. Use a single schema where every table with per-customer data has a tenant id column. Most decent RDBMS have a good way to ensure isolated locks across tenant ids e.g. MySQL partitions.
- leesalminen 11y ago
  Understood. Currently, I manage several hundred logical databases for a B2B SaaS product. This has the potential to grow to several thousand over the course of years. My customers enjoy that (arbitrary) piece of mind that their data is logically separated from all else. I enjoy not having to remember to include a tenant_id clause. Our traffic pattern is quite steady per hour of day and per customer. That, plus using RDS for horizontal scaling (fixed # of logical DBs per host) allowed us to take this route. I suppose the decision is a matter of circumstance and preference, but I don't think this is necessarily "wrong" to do.
  - beachstartup 11y ago
    it's going to work fine until it doesn't. that's not going to be a good day. smart people can rationalize anything.

beachstartup 11y ago

see? LOTS.

bpchaps 11y ago

An ungodly amount of reasons. The ability to manage that many, for one. Those poor devops folk who have to deal with that. On a more technical side as an example, the number of open files can only be so high. You really start to hit the limit when you do things like that, which is when the most interesting kinds application crashes happen. "Just increase the file count." results in "Our report shows that an OldServer did not include a necessary open file limit config change. Engineer #582 has been fired."

leesalminen 11y ago
CLI tooling has solved a lot of the problems that arise from many. Scripts for migration, host transfer, creation and deletion took some time to build out, but do work fine. I suppose we are lucky to have a very consistent workload per logical database. This allowed us to calculate our costs ahead of time. We found that we could keep DB costs at ~$1/customer/month. For a B2B SaaS product we were satisfied with that cost.

joncampbelldev 11y ago

My personal preference for a single multi-tenanted schema as opposed to 2000+ schemas is: Unless you require per customer customisations (which is a fast way to ensure you have an upper limit on the number of customers you can support) there is no need to duplicate. Use a single schema where every table with per-customer data has a tenant id column. Most decent RDBMS have a good way to ensure isolated locks across tenant ids e.g. MySQL partitions.

leesalminen 11y ago
Understood. Currently, I manage several hundred logical databases for a B2B SaaS product. This has the potential to grow to several thousand over the course of years. My customers enjoy that (arbitrary) piece of mind that their data is logically separated from all else. I enjoy not having to remember to include a tenant_id clause. Our traffic pattern is quite steady per hour of day and per customer. That, plus using RDS for horizontal scaling (fixed # of logical DBs per host) allowed us to take this route. I suppose the decision is a matter of circumstance and preference, but I don't think this is necessarily "wrong" to do.
- beachstartup 11y ago
  it's going to work fine until it doesn't. that's not going to be a good day. smart people can rationalize anything.