Designing Multi-Database Systems
By Skyrit Lai
Serving several organisations from one application can require more than an additional connection string. Data boundaries, migrations, observability, and operating responsibility all become architectural concerns.
01 / Architecture
Isolation is an operating choice
A separate database can support stronger boundaries, different retention needs, and independent scaling. It also creates new responsibilities around provisioning, monitoring, and change management.
02 / Architecture
Keep application context explicit
The application needs a reliable way to resolve the right data boundary for each request or workflow. Logging and telemetry should preserve that context so issues can be investigated.
03 / Architecture
Plan for the whole lifecycle
Migrations, backups, recovery, and operational tooling should be designed before the architecture becomes difficult to change. A multi-database model is governance as much as technology.
The thought to take with you
A data boundary is valuable when the team can operate it as deliberately as it can design it.
Related work
Where this thinking shows up.
Software systems and data
Put the thinking into practice.
Note
The Best System Architecture Often Begins Outside the System
Database schemas and APIs are downstream of business rules. When the domain is misunderstood, clean implementation can still encode the wrong reality.
Note
Structuring Data for Scale with PostgreSQL Partitioning
As operational data grows, predictability matters as much as raw query speed. Partitioning can help a data model reflect time, tenant, retention, and maintenance boundaries more deliberately.
Note
Making Deployments Observable and Reversible
A production change becomes safer when the team can see what happened, decide whether the release is healthy, and return to a known state without improvising under pressure.