SaaS development company in India
We build SaaS products and MVPs (minimum viable products: first versions you can put in front of customers) that many customers use at once. A tenant is usually one customer. We help you choose how each tenant's data is stored and kept apart, then enforce that choice in the database, not just at the login screen.
What we do
Three jobs, whether we're building your MVP or working in code you already have.
Tell us who your customers are and whether any of them will need its own database. We base the choice on published AWS, Microsoft and PostgreSQL guidance, and show you the trade-offs before the data layer is built or changed.
Depending on the model, we build in tenant IDs, row-level security (a database rule that returns only the current tenant's rows) and default deny, so a protected table with no rule returns no rows.
Our security practice reviews our builds before launch. On a SaaS product, the question that matters most is whether one tenant can reach another tenant's data.
SaaS is part of our web and custom software work. Still deciding whether to build at all? See custom software development. If your customers already send you security questionnaires, see security and compliance for SaaS companies.
An early storage decision
Not with the login screen. Signing in proves who a user is. AWS's SaaS Lens says that is not the same as isolation.
Microsoft's Azure SQL Database guidance says a tenancy model sets how each tenant's data is stored. The choice generally doesn't change what your application does, but it is likely to affect the rest of the solution around it. In Microsoft's words: “Switching to a different model later is sometimes costly.”
PostgreSQL is the database in our published technology stack. AWS Prescriptive Guidance compares four ways to partition (split up) tenant data in it, side by side:
None of the four is right for every product. Which one fits depends on your tenants, and the comparison below shows where they differ.
AWS's PostgreSQL matrix
AWS scores the options against 28 criteria. By our count, the four options get the same answer on none of them. Here are five of the rows.
| Criterion | Silo and both bridge options | Pool |
|---|---|---|
| Data isolation | Silo best; bridges better, using PostgreSQL roles | Worse; needs features such as row-level security |
| New tenant onboarding agility | Silo very slow; bridges moderately slow | Fastest; minimal setup |
| Change deployment: scope of impact | Minimal: a single tenant is affected | Very large: all tenants are affected |
| Tenant-level backup and recovery effort | Silo least effort; bridges moderate | Significant effort; tenants share tables |
| Per-tenant customization | Possible | Complicated, since tenants share tables |
For engineers: three things follow when tenants share a database. AWS and Microsoft weigh row-level security differently, as the last two show.
How we work
The order is ours: a tenant has to be defined before it can be isolated.
We start by agreeing with you what a tenant is. Often it is one customer, but not always. Microsoft's Azure Architecture Center says a single customer might need to map to several tenants when its subgroups have different requirements.
Next we settle how each signed-in user is tied to a tenant. AWS's Well-Architected SaaS Lens (April 4, 2023) sees identity as where multi-tenancy tends to begin. It asks how tenant context (the record of which tenant a request belongs to) is tied to users and applied across the architecture.
Then we settle where the isolation check sits. The SaaS Lens says isolation enforcement should not be left to service developers, so where it sits is a design decision in itself.
Last, we settle how the application finds each tenant's data. In AWS's silo model, an application or data access layer has to map each tenant to its own PostgreSQL instance, so that mapping is part of the build.
MVP development company · Owner's decisions
These are the tenancy questions only you, as the owner, can answer. Keeping tenants apart is also a published security requirement: OWASP ASVS 5.0.0, a public application security standard, lists cross-tenant controls for multi-tenant applications as v5.0.0-8.4.1, a Level 2 requirement.
Where a payments tenant's data may sit is covered for India on our PCI DSS compliance page.
The Digital Personal Data Protection Act, 2023 defines a Data Processor in section 2(k) as “any person who processes personal data on behalf of a Data Fiduciary”. When your product does that for a business customer, the customer is the Data Fiduciary in that definition.
The definition commenced with the Act's first tranche. The duties that follow for the customer sit in section 8, which our DPDP Act compliance page dates to May 2027.
What tenancy does not cover. Tenancy is about one customer's data against another's. Where an application checks which records one user may open, and what an API returns for a record the caller may not see, are separate questions with their own pages.
For per-user record checks, see web application development. For the status code a caller gets, see API development and integration.
FAQ
Login screens, separate databases, row-level security, keys and AI search. For anything else, ask us directly.
No. AWS's Well-Architected SaaS Lens says authentication and authorization are not the same as isolation, and that getting past a login screen or an API does not mean isolation is achieved. Microsoft's Azure Architecture Center says tenants sharing one deployment are typically kept apart by application code and a tenant identifier in a database.
Not necessarily. AWS's PostgreSQL decision matrix points to silo, an instance or cluster per tenant, when isolation with full control of resources is key or tenants are very large and performance-sensitive, and to pool for many tenants with less data each. Microsoft says a solution that need not scale to many tenants, or has no performance or isolation concern, is better kept simple.
No. PostgreSQL 18 documentation, section 5.9, says superusers and roles with the BYPASSRLS attribute always bypass row security, and table owners normally do too unless FORCE ROW LEVEL SECURITY is set. Whole-table operations such as TRUNCATE are not subject to it, and referential integrity checks always bypass it, so schemas and policies need care, or data can still leak indirectly (a covert-channel leak).
In AWS's PostgreSQL decision matrix, only silo, an instance or cluster per tenant, gives each tenant its own AWS KMS (Key Management Service) key for storage encryption; the bridge options and pool use one shared key. Microsoft says tenants that bring their own keys may need tenant-level encryption, which SQL Server and Azure SQL offer through Always Encrypted.
It can, if the product searches tenants' documents. Microsoft's guidance for its own search service says relevance scores are computed across the whole index rather than per tenant, so statistics such as term frequency draw on every tenant's data. Whether tenants share a retrieval index is then a tenancy decision too.
Yes, if the codebase was designed for both. Microsoft's Azure Architecture Center says code must be designed to handle multitenant and single-tenant deployments, and that allowing migration means planning how customers move to their own deployment. AWS's SaaS Lens describes its bridge model as acknowledging that SaaS businesses are not always purely silo or pool.
Let's talk
Say who your customers are and whether any of them will need its own database. Project work is delivered remotely from India during business hours. We reply within one working day.