Hello I’m planning ahead for growth and thinking about database scaling in a multi-tenant n8n automation platform.
Right now, all tenant data is stored in a single PostgreSQL database:All Tenants → Shared PostgreSQL Database
This works fine today, but I’m concerned about:
Database growth over time
Query performance
Backup/restore complexity
Noisy tenants affecting others
Future scaling limits
I’m considering:Single DB with tenant_id partitioning
Schema-per-tenant
Database-per-tenant
Sharding tenants across multiple databases
Tenant A-M → DB1
Tenant N-Z → DB2
Tenant A → DB A
Tenant B → DB B
Describe the problem/error/question
When did you decide to shard?
Did you use partitioning, schema-per-tenant, or database-per-tenant?
How do you balance isolation, cost, and operational complexity?
Any lessons learned before scaling to hundreds or thousands of tenants?
What is the error message (if any)?
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
Hello @Keira_Becky For most multi-tenant platforms, don’t shard too early. Single DB → Partitioning → Sharding (if needed)
Many teams start with: One PostgreSQL database
tenant_id on all tables
Proper indexing and partitioning
This can handle a surprisingly large number of tenants.
When to consider sharding
Usually when you start seeing:
Large tables affecting performance
Backup/restore becoming difficult
Very large tenants impacting others
A common pattern is: Small/Medium Tenants → Shared DB
Large Tenants → Dedicated DB
This provides better isolation without the complexity of full sharding.
Try to Avoid
Database-per-tenant too early
Complex sharding before you have a scaling problem
Managing hundreds of databases unnecessarily
This is incredibly helpful and gives me a much clearer understanding of how to approach multi-tenant scaling. I appreciate you taking the time to share your insight
One important n8n-specific constraint that’s worth calling out: n8n itself stores all its internal state (workflows, credentials, executions, user data) in the same PostgreSQL database. You can’t easily shard n8n’s own tables across multiple databases. So for true multi-tenant isolation at scale, the most practical approach is actually separate n8n instances per large tenant (or per tenant tier), each with their own PG. Small/medium tenants share an instance, enterprise tenants get a dedicated one. This avoids the sharding complexity entirely and gives you natural isolation for backups and noisy-neighbor issues.