On 9/29/2016 2:25 PM, Venkata B Nagothi wrote:
> Since, you are saying there could be thousands of tenants, going for
> single-database-per-tenant could possibly end up in a very bad and
> complex database design.
>
worse, it would also require each tenant to have unique connections,
making connection pooling a nightmare.
depending on the nature of the application, its data isolation
requirements, and how much per-tenant customization there is, assuming
the customers('tenants') aren't directly accessing SQL, I could see many
scenarios with ONE database+schema, and 'tenant' is just a field that
qualifies queries. From a pure performance standpoint, this likely
woudl be the most efficient, as 1000s of schemas with 100s of tables
each == 100s of 1000s of tables, which means massive bloat of the
postgres catalog, and also makes caching less effective.
--
john r pierce, recycling bits in santa cruz
