Multi-tenant SaaS separates customers with a tenant-id column and code that must never be wrong. A database per business makes isolation a physical boundary.
Multi-tenant SaaS keeps every customer in one shared database, separated by a tenant-id column and application code that must never make a mistake. It is efficient, it is the industry default, and it means your data and your competitor's data are rows in the same table.
Vritti gives each business its own database. Isolation is not a query filter; it is a physical boundary.
What changes about correctness
In a shared database, a missing WHERE clause is a data breach. Every query, every report, every background job has to carry the tenant filter, forever, across every developer who ever touches the codebase.
With a database per business, that class of bug cannot cross a customer boundary because there is no other customer in the database to reach. As a second line of defence, row-level security is enforced by Postgres itself through a non-owner role, so isolation holds even if application code is wrong.
What changes about operations
Backups become yours. Continuous backup with point-in-time restore means you can rewind your data to a chosen minute, rather than restoring a shared nightly snapshot that would affect everyone.
Restores stop being a negotiation. In a shared system, restoring one customer's bad afternoon is a surgical extraction. With your own database, it is a restore.
Without becoming your own ops team
The usual objection to a dedicated deployment is that somebody now has to run it. That is the half Vritti Cloud handles.
Cloud describes a desired state — every service, its image and its runtime settings. An agent on your deployment reconciles toward that state, verifying an Ed25519 signature on the payload before applying anything, so nothing can be injected in transit. Certificates issue and renew themselves. Services that stumble get restarted.
You get ownership of the data and the boundary, without inheriting the pager.