The solution I've seen the most is to have a "landlord" database and one "tenant" database per client. The landlord DB acts as a kind of router to select the tenant DB, based for example on the subdomain being used.
This allows for better scalability, isolates sensible information between clients and simplifies the queries as you don't need to specify the tenant name for every SQL operation.
Going this way directly is not premature optimization I think. If you go the single DB route directly it becomes difficult to refactor to a multitenancy later on.
This is not the only way to implement such a system of course. There is a good podcast covering the subject here: fullstackradio.com/episodes/80
The solution I've seen the most is to have a "landlord" database and one "tenant" database per client. The landlord DB acts as a kind of router to select the tenant DB, based for example on the subdomain being used.
This allows for better scalability, isolates sensible information between clients and simplifies the queries as you don't need to specify the tenant name for every SQL operation.
Going this way directly is not premature optimization I think. If you go the single DB route directly it becomes difficult to refactor to a multitenancy later on.
This is not the only way to implement such a system of course. There is a good podcast covering the subject here:
fullstackradio.com/episodes/80
This sounds kind of like a load balancer :)
Indeed, they both are layers of indirection 🙂