Frequently asked questions
- Should we start with separate databases per tenant?
- Usually no—shared schema with strict row-level tenant_id and tested isolation scales further for most B2B SaaS.
- What is the most common multi-tenant bug?
- Missing tenant filter on one query—use middleware and integration tests that fail closed.
- When does APLINDO recommend siloed databases?
- Regulated tenants, very large enterprises, or contractual data residency that cannot share a cluster.
Founders ask for features. Investors ask for margins. Security asks for proof tenants cannot see each other's data. If you skip the baseline, every later feature ships with a latent breach.
What belongs in a multi-tenant baseline?
- Tenant context everywhere —
tenant_idon rows, in JWT claims, in logs, in metrics. - AuthZ that defaults deny — RBAC or ABAC with policy tests, not ad-hoc
if (user.isAdmin). - Config per tenant — Feature flags, branding, webhooks without redeploying the monolith.
- Noisy-neighbor controls — Rate limits and queue fairness per tenant.
- Migration strategy — How you onboard, offboard, and export a tenant's data (PDP matters).
How does APLINDO implement this?
We have shipped multi-tenant stacks for products like RTPintar, Patuh.ai, and BlastifyX, plus custom SaaS for Jakarta enterprises. We prefer Postgres row-level patterns with explicit integration tests over premature shard-per-tenant complexity.
Key takeaways
- Tenant isolation is a test suite, not a comment in the README.
- Per-tenant observability saves hours when one customer reports slowness.
- Add siloed databases only when contracts or scale force it—not on day one.