Multi-Tenant Architecture for South Asian SaaS: The Decisions We Made and Why

Multi-tenancy is a solved problem in theory. The literature on it is extensive. The AWS well-architected framework has a section on it. Every major SaaS platform uses some form of it.

Building multi-tenant SaaS for South Asian markets is something else entirely. The assumptions baked into every English-language architecture guide — reliable broadband, card-based payments, single-language interfaces, GDPR or similar regulatory frameworks — don't hold.

Here's how we've approached it for the products we ship.

The three models of multi-tenancy and why we chose a hybrid

The traditional choice is between silo (one database per tenant), pool (shared database with row-level tenant isolation), or bridge (separate schema per tenant in a shared database). Each has tradeoffs that are well understood in theory.

• Silo: Strong isolation, easy customisation, expensive at scale, operational overhead grows linearly with tenants.
• Pool: Cheap to run, scales well, harder to isolate data, one bad query can affect all tenants.
• Bridge: Middle ground — schema isolation without the full cost of silo. PostgreSQL handles this well with schema namespacing.

We use a bridge model for most of our products: shared PostgreSQL cluster, with each tenant getting their own schema. This gives us the operational benefits of a shared database while providing meaningful data isolation and the ability to run tenant-specific migrations without touching other tenants.

Why bridge works for our market

Our tenants are typically SMEs — 50 to 500 employees — and their data volume is modest by Western standards. We're not running Shopify-scale tenants. The bridge model lets us run 200+ tenants on infrastructure that would cost ৳15,000/month rather than ৳150,000/month.

The other reason: compliance. Bangladesh doesn't yet have a comprehensive data protection law equivalent to GDPR. But our larger clients — particularly in financial services and healthcare — have internal data governance requirements that mean they want to know their data is isolated. "Your own schema" is a concrete and understandable answer to that concern.

Payment infrastructure: the problem nobody talks about

Every South Asian SaaS product eventually hits the payment infrastructure problem. Stripe doesn't operate in Bangladesh. Braintree doesn't. PayPal is available but has friction and currency conversion costs that kill conversion for local customers.

We built our payment layer on top of a combination: bKash and Nagad for local mobile money, SSL Commerz for card payments (the dominant payment gateway in Bangladesh), and manual invoice + bank transfer for enterprise clients who won't use online payment. That last category is bigger than you'd expect — many Bangladeshi CFOs prefer wire transfers for software subscriptions because it fits their expense approval processes.

Language and localisation: more than font rendering

Bengali is the national language of Bangladesh and one of the most spoken languages in the world. It's also, frankly, a pain to build software around — not because the language is complex, but because most software infrastructure assumes left-to-right, Latin-script text.

Database collation matters. Sorting Bengali text alphabetically requires a different collation than sorting ASCII. PostgreSQL supports Bengali via the bn_BD locale, but it needs to be set explicitly and consistently. We've seen systems where collation was set incorrectly at creation and was never discovered until a Bangla-language search feature returned wrong results.

Input method: many users in Bangladesh switch between English and Bengali mid-sentence — phone numbers and model numbers stay in English, descriptions are in Bengali. Our forms need to handle mixed-language input gracefully, including in search.

PDF generation with Bengali text is its own problem. We use a Puppeteer-based PDF service with a custom Bengali font stack rather than a PDF library, because most PDF libraries don't handle complex script rendering correctly.

Connectivity: designing for degraded conditions

Internet infrastructure in Bangladesh has improved dramatically over the last decade, but reliability outside Dhaka is still inconsistent. Mobile data is widespread — over 95% penetration — but connection quality varies significantly.

We design our front-ends with an explicit degraded mode. Key workflows — especially data entry — are built to survive a 30-second connectivity loss without losing user data. We use optimistic UI updates with background sync rather than blocking the UI on every API call.

• Form data is persisted to localStorage before submission — if the submission fails, the draft is recoverable.
• List views cache their last successful fetch and show stale data with a clear indicator rather than a loading spinner.
• Critical operations (order confirmation, payment processing) show a clear "submitting" state and don't allow re-submission during inflight requests.

The parts we got wrong the first time

We initially built tenant provisioning as a synchronous operation — creating the schema, running migrations, and seeding default data all in the same request that handled account signup. This worked for our first 20 tenants. By tenant 50, provisioning was taking 8–12 seconds and timing out on slow connections.

We moved provisioning to a background job queue (using BullMQ). Signup now returns immediately with a "setting up your account" message, and the user gets an email when their workspace is ready. This is how every major SaaS platform handles it, and the reason is exactly what we experienced.

The lesson: build for your real scale, not your current scale. Even at 50 tenants, background job queues are worth the setup cost.