1

I am using MYSQL so Database is the Schema, sorry if not using right terminology.

I currently have a Saas product which has multiple databases one for each client with a main databases which we reference for account names and connections to the individual client databases.

I am starting a new Saas product and wondered if this is the right approach for scalability.

I have read many posts on this but a lot are old posts and was wondering if anyone could offer opinion on which approach currently works best for scalability,

What is easier to scale one db or multiple db with sharding/partitioning?

Which approach is better/easier for connection pooling?

Which approach is better for query read/write speeds, is one large database better than 100s of small dbs?

Which approach is better on server CPU/Memory usage one large database better or 100s of small dbs?

I use AWS RDS, Thanks in advance.

closed as off-topic by Mark Storey-Smith, Michael - sqlbot, RolandoMySQLDBA, RLF, Max Vernon Oct 14 '14 at 13:28

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Tip of the iceberg - the question or comments reveal an underlying issue that would need extensive investigation by a consultant or database vendor support team: issues like this do not fit the SE Q&A model well. For more information see this meta post." – Mark Storey-Smith, Michael - sqlbot, RolandoMySQLDBA, RLF, Max Vernon
If this question can be reworded to fit the rules in the help center, please edit the question.

0

There is no performance difference between single base and number of bases, because "schema" is just the domain of authority. Grouped together or aparted, tables stored and processed in the same way. From the administrative point of view multiple bases are bit preferrable as far as you can dump the whole data for single client by DB name, not the pattern for the mangled tablenames.

Sure your experience may vary.

Not the answer you're looking for? Browse other questions tagged or ask your own question.