A SaaS product adding tenants in new countries is usually best served by one general-purpose relational database design with a tenant key, region stored on each tenant, and one deployable stack repeated per region only when a customer or a law requires it. Start global, add regions on demand, and keep a small global directory.
The question behind this topic is rarely "which database brand". It is "where does each tenant's data live, and how little must I duplicate to put it there?" This guide separates those questions. It compares the patterns for regional data, explains what usually stays global, and shows how to avoid running a full copy of everything for every country. It does not give legal advice: residency rules differ by country, by type of data and by customer contract, so confirm the requirement for each country with qualified advisers before you design. It builds on our multi-tenant SaaS architecture guide, which compares the tenancy models and briefly covers regions, and on our guide to moving from single-tenant to multi-tenant when tenants already live in separate installs. Regional capacity is also affected by heavy tenants, which our noisy neighbour isolation guide covers. For help designing a product like this, see our SaaS development company page.
Key takeaways
- Decide the requirement before the technology. For each target country, find out whether data must stay in-country, may leave with safeguards, or is unrestricted, and for which data types.
- Residency covers more than the main database: replicas, backups, logs, search indexes, file storage, analytics, messaging providers, support tools and any AI services you call.
- Make region a property of the tenant, with a global directory that routes to it. This is cheap to add early and expensive to retrofit.
- Package the stack as repeatable code, so a region is a parameter. Most cost comes from the minimum footprint of each region.
- Cross-region reporting should use aggregated or de-identified data, unless an adviser confirms that copying personal data is acceptable.
- Add a region when a contract or law demands it, not in advance.
What database should you choose for a SaaS product that adds tenants in new countries over time?
Choose a database you can run in each region you need, with strong transactions and tenant scoping. For most B2B SaaS that means a mainstream relational database such as PostgreSQL, MySQL or SQL Server (examples, not a ranking) with a tenant key, offered as a managed service in each target region.
Apply these filters in order:
- Availability. Does your cloud or hosting provider offer the database service in a region that satisfies each target country? Confirm on the provider's current region list and service availability page.
- Operational fit. Can your team run it, back it up, restore it and migrate it in many regions? A familiar database operated well beats an exotic one operated badly.
- Tenant scoping. Does it support row-level policies, schemas or separate databases, so you can use the isolation model each tenant needs?
- Scale path. If one region outgrows a single instance, can you add read replicas, partition by tenant, or move large tenants to their own database?
- Distributed options. Some distributed SQL databases can pin rows or partitions to a region inside one logical database. They can simplify a single global schema, but they bring their own operating model, so evaluate them on the same filters rather than assuming they replace regional deployments.
What does data residency cover?
Data residency is where data is stored and processed, and who can reach it. A database in the right country is only part of it. Backups, replicas, logs, caches, search indexes, uploaded files, analytics, email and SMS providers, support tooling and AI services can all hold copies elsewhere.
| Place data can live | Question to ask |
|---|
| Primary database | Which region hosts it, and who administers it? |
| Encryption keys | Which region holds the keys, and who controls them? |
| Replicas and backups | Are they kept in the same region or country, including disaster recovery copies? |
| Logs, traces and error reports | Do they contain personal data, and where are they stored? |
| File and object storage | Which region is each bucket in? |
| Search indexes and caches | Are they rebuilt from regional data, in the same region? |
| Analytics and data warehouse | Does raw tenant data leave the region, or only aggregates? |
| Messaging, payment and email providers | Where do they process the data? |
| Support and administration access | Can staff in another country view tenant data, and how is it logged? |
| AI and third-party services | Is tenant data sent to a service outside the region? |
Residency requirements also differ in kind: some rules require storage in a country, some restrict transfers unless safeguards exist, and some customers impose a region by contract even where the law does not. Your legal and compliance advisers should state the requirement for each market, and your contracts should name the region.
Which patterns let you serve tenants in several countries?
There are five common patterns, and most products combine two. They differ in how much infrastructure each region needs, how much of the stack is shared, and how clearly you can show where a tenant's data lives. Pick the simplest one that satisfies the requirement your advisers have confirmed.
| Pattern | How it works | Strengths | Trade-offs |
|---|
| Single global deployment | One database and one application stack, tenants separated by a tenant key | Lowest cost and effort | Cannot satisfy in-country storage requirements |
| Global application, regional databases | Application tier shared, each tenant's data in a database in its region | Fewer moving parts than full regions | Cross-region latency between application and database; the application tier may itself process data outside the region |
| Regional cells (full stack per region) | A complete copy of application, database, queues and storage in each region, with a global directory | Clear residency story, lower latency, failures stay contained | More to operate; every release must reach every cell |
| Geo-partitioned distributed database | One logical database pins rows or partitions to regions | One schema, one query interface | Specialised operations; confirm exactly where replicas and backups sit |
| Database per tenant in a chosen region | Each tenant has its own database placed in its region | Strong isolation and simple per-tenant region | Many databases to manage; best for high-value tenants |
A cell is a self-contained copy of the stack that serves a subset of tenants. The idea also limits the blast radius of a failure or a bad release, because a problem in one cell does not reach the others.
What stays global, and what moves into the region?
Keep global only what contains no regulated tenant data and what you need to route: a tenant directory (tenant, region, status), release and deployment management, and aggregated operating metrics. Put tenant content, user personal data, files, logs with personal data and regional backups inside the region.
Identity needs a decision. Sign-in has to find the tenant's region before it can check a user, so common designs use a small global lookup (by email domain, tenant code or regional sign-in address) that returns only the region, then authenticate in the region. Billing may be global if it holds company details but not tenant content; confirm that with your advisers. Whatever you choose, write down what is global and why.
How do you route users to the right region?
Store the tenant's region in the directory, and route by something known before authentication: a tenant-specific subdomain or custom domain, a regional sign-in address, or a lookup that returns only the region. Never route using client-supplied claims alone, and make the regional service verify that the tenant belongs there.
Add a safeguard: the regional stack should refuse requests for tenants it does not host. That turns a misrouting bug into an error rather than a data leak. Test onboarding, tenant moves between regions and sign-in from travelling users.
Plan the move of a tenant to another region as a procedure: export, load into the new region, verify, switch the directory entry, then delete the old copies, including backups and logs, once the retention rules allow.
How do you report across regions?
Cross-region reporting works by sending aggregated or de-identified results out of each region, not by copying raw records into one place. Each region computes its own figures, and a global reporting store receives totals, counts and averages. Whether such data is acceptable to move depends on the rules that apply, so confirm that first.
Options:
- Regional dashboards. Each region has its own reports; head-office users switch region.
- Aggregate export. Scheduled jobs send per-tenant or per-region totals to a global store. Keep them free of personal data.
- Federated queries. A query layer asks each region for its part and merges the answers. This avoids bulk copying, but only aggregated results should leave a region, because returned personal data is still a transfer. It needs careful performance and permission design.
- Customer-side exports. Tenants export their own data when they want to combine it.
How do you add a country without multiplying infrastructure?
Make a region a parameter, not a project. Define the whole stack as repeatable infrastructure code, keep the minimum footprint small, serve several nearby countries from one region where requirements allow, and add a region only when a customer or a requirement demands it. Reuse one code base and one release process.
| Cost driver | Why it grows with each region | How to contain it |
|---|
| Minimum footprint | Each region needs a database, redundancy, networking and monitoring even with few tenants | Use the smallest viable size and scale on demand |
| Operations | Releases, migrations, backups and restore tests must cover every region | Automate; deploy region by region |
| Version skew | Regions on different releases confuse support and integrations | Keep one release line, with controlled rollout order |
| Replication and transfer | Moving data between regions costs money and creates residency questions | Avoid cross-region copying of tenant data |
| Observability | Logs and metrics are also data | Keep regional logs in region, share aggregates |
| Support | Staff need access rules per region | Time-limited, logged, region-aware access |
| Disaster recovery | A backup region must also meet the requirement | Choose recovery targets inside the same legal area |
Worked example (illustrative numbers)
A SaaS product has 300 tenants in one region and gains its first customer that needs data kept in another country. The team adds a region property to every tenant, a tenant directory and a regional sign-in lookup, then deploys a second cell from the same infrastructure code with a small database and no read replicas. Eight tenants in that country move over in the first phase, and three neighbouring countries share the cell after the team's advisers confirm that is acceptable. Reporting sends monthly aggregates to a global store. The numbers are illustrative; the point is that the second region reuses the first region's code, and the third does not need another design.
When is this the wrong approach?
Regional cells are the wrong choice when no customer or rule requires them, because you pay for duplicated operations without a benefit. A single global deployment with strong tenant isolation is simpler and cheaper. Treating region as a purely technical setting is also a mistake when the real question is legal or contractual.
Glossary: Data residency, where data is stored and processed. Cell, a self-contained copy of the stack for a set of tenants. Control plane, the global part that manages tenants and releases. Tenant directory, the lookup of tenant to region.
How Timeline Digital approaches this
Founded in 2013 in Islamabad, Pakistan, Timeline Digital delivers custom software remotely. For a product that must serve several countries we start by understanding your target markets and the requirements you have confirmed with your advisers, set the schedule from your requirements in the Plan step (there is no fixed timeframe), and can build a free pilot of 2 to 3 key modules, such as the tenant directory and routing, for you to test before the final agreement. Source code transfers to you on full payment.