3 ms·
Perhaps I'm missing something, but to me the obvious way to serve multiple clients is to simply create multiple isolated deployments, including a separate datab
by tener 10y ago
Perhaps I'm missing something, but to me the obvious way to serve multiple clients is to simply create multiple isolated deployments, including a separate database server for every client.
Handling this on the application level feels like unnecessary complexity.
Any good reasons to go with the approach described in the blog post?
- arethuza 10y agoWhat if you want to support a very large number of relatively small tenants - having a separate server for each one of those could well be overkill.
- geocar 10y agoQuerying across multiple schemas can be useful, for example if: • You want easy administrative controls for impersonating a customer • You want to run business queries across multiple customers • You integrate authentication with your database, so you don't need a separate service to tell your application "which" database endpoints to use with your username. • You want to simplify sysadmin job of managing a single database instead of thousands of databases. And so on. Sometimes these things are worth giving up the "simple" isolation.
- eternalban 10y ago> including a separate database server for every client .. .. is actually a kind of "[h]andling this on the application level", with "this" being the Postgres' process management. Each database gets its own daemon and it is this per-database process that is responsible for launching a peer process for each connection. There are likely legitimate use cases for multiple PG databases per node, but multi-tenancy is not one of them.
- ozgune 10y agoCompared to the one database per tenant method, this approach scales to more tenants with fewer resources. In particular, you're now asking the database to manage HW/SW resources (cpu, ram, disk, network, and OS resources) for your tenants, instead of allocating those resources to different databases yourself.