使用AWS re:Post即您表示您同意 AWS re:Post 使用条款

Aurora PostgreSQL - recommended maximum number of databases (for a multi-tenant data layer)

0

Hello,

TL;DR - I have a customer who has a SaaS solution which includes multi-tenant data layers. They want to improve their tenant isolation by creating a logical DB per tenant.

Aurora Postgres is a main component of the architecture. In order to create better isolation, they would like to create a database per tenant (to clarify: multiple logical databases within the same cluster). They ask whether a single Aurora PostgreSQL cluster can hold 10K DBs.

  1. Is this a reasonable requirement from Aurora Postgres (and from PostgreSQL at all)?

  2. In which point (regarding DBs number) solutions like sharding will make sense? (talking only about the number of DBs in a cluster. To clarify - I'm also discussing with them about each DB performance requirements, availability requirements, etc..)

  3. In addition, I am discussing with the customer about other considerations, like dividing the DBs in order to create better maintenance / operations abilities and limit the blast radius of one cluster).

Many thanks in advance.

AWS
已提问 6 年前3001 查看次数
1 回答
0
已接受的回答

Multi-tenant DB architecture will come down to their use case, as you've hinted to. There are lots of papers/articles out there that discuss tradeoffs with alternative approaches when it comes to isolation, maintainability, migrations, development pain, schema changes, and other factors.

Given that, I'll try and focus my answer on 1&2 in your question: We certainly have customers on both Aurora and RDS Postgres with 10k databases. Some even orders of magnitude more. It works. However, they'd certainly want to think about their future plans for scaling. There is a point where even just the sheer number of files generally causes Postgres (or the OS) grief. If their schema is complex, with many relations per database, then they could run in to issues much sooner. It's tough to give solid numbers, but at 10k you could say it's feasible enough for them to put in the effort to do a real evaluation.

Another potential sticking point is connection management. If their workload calls for frequent access to many customers/databases, it's worth mentioning that Postgres is connection-per-database. Even at 10k, they won't realistically be able to pool connections for all customers. Creating and tearing down connections will introduce overhead they wouldn't otherwise encounter with something like table-per-customer.

There are a lot of other things to consider as I mentioned, but yes, people do 10k databases. As always, they should test using something representative of their specific workload.

AWS
已回答 6 年前
profile picture
专家
已审核 5 个月前

您未登录。 登录 发布回答。

一个好的回答可以清楚地解答问题和提供建设性反馈,并能促进提问者的职业发展。

回答问题的准则