The three options are a shared schema with a tenant id column, a schema per tenant, and a database per tenant, trading operational simplicity against isolation. Shared schema scales best and costs least but requires the tenant filter to be enforced structurally, for example with row level security or a data layer that always applies it. Database per tenant gives the strongest isolation and the easiest per customer restore, at a real operational cost.
Why interviewers ask this
This is an architecture question with obvious commercial consequences: it affects onboarding cost, noisy neighbors, compliance promises and how you restore a single customer's data. The interviewer wants a tradeoff discussion, not a favorite. Mentioning row level security, migration effort across thousands of schemas, and per tenant backup and export tells them you have thought past the first design meeting.
How to structure your answer
- Lay out the three models along an isolation and cost axis.
- State your default and the conditions that would change it.
- Explain how you enforce the boundary structurally, not by convention.
- Cover operations: migrations, backups, per tenant restore and noisy neighbors.
Example answer
My default is a shared schema with a tenant id on every table, because it is the cheapest to run and onboarding a customer is one insert rather than a provisioning job. The danger is obvious, one missing where clause leaks data across customers, so I never leave that to discipline. I use row level security with the tenant set from the authenticated session, so even a hand written query returns nothing outside the tenant, and I add tests that deliberately try to read another tenant's rows. I move to a schema or database per tenant when there is a real driver: a customer with a contractual data residency requirement, a handful of enterprise accounts big enough to be their own load, or a compliance regime that wants provable separation. The costs are the ones people underestimate: a migration now runs across every schema, connection pooling gets harder, and you need automation for provisioning and per tenant restore. I have also had to solve noisy neighbors separately, with per tenant rate limits, because isolation of data is not isolation of capacity.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How would you restore one customer's data from backup in a shared schema?
- How do you run a schema migration across thousands of tenants safely?
- How do you stop one large tenant degrading everyone else?
Related backend developer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions