SaaS back-end with separated tenants, plans and limits
We build the back-end of SaaS products that serve many companies from one platform: data separated by customer, plans, usage limits and metering of what each one consumes.
Who it's for
For software companies whose product has grown, yet every new customer still needs its own installation.
What it solves
- Every new customer needs a copy of the system and an afternoon of setup.
- One forgotten filter in a query can show one customer's data to another.
- The plans exist on the pricing page, but the system cannot enforce them.
- One large customer slows the system down for everyone else.
- Nobody knows how much each customer uses until the cloud bill arrives.
What we do
- Tenancy model
- Shared database, schema per customer or database per customer, chosen by risk and cost.
- Data isolation
- Every query is filtered by customer in the database itself, with row-level security.
- Plans and limits
- Features, user counts and quotas for each plan enforced by the system itself.
- Usage metering
- Each customer's consumption is counted and ready for billing and checking.
- Heavy customers kept in check
- Request quotas and separate queues, so one heavy customer does not delay the rest.
- Administration API
- Create, suspend, change plan or export a customer through an API, without touching the database directly.
What you get
- A documented tenancy model, with the decision and reasons on record
- Automated tests that try to read another customer's data and must fail
- Per-customer usage metering, ready to export for billing
- An administration API for customers, plans and limits
- A migration plan, when the product already runs customers on separate installations
How we do it
Assessment
How the product serves customers today and where data gets mixed or duplicated.
Model decision
Shared or separate, weighing risk, cost and what customers require by contract.
Development
Isolation, plans, metering and administration, with tests for leaks between customers.
Staged migration
Existing customers move to the new platform in groups, with a way back.
Follow-up
Usage and performance per customer, and tuning of the limits.
Technology examples
- PostgreSQL
- Row-Level Security
- Redis
- OpenAPI
- Kubernetes
- OpenTelemetry
Related services
FAQ
One database per customer, or one for everyone?
It depends on risk, cost and what your customers require by contract. The two can also be combined: a shared database for most, a separate one for those who ask.
Can this be done without rewriting the product?
It depends on how the code separates customers today. Where it can, the change comes in parts: isolation first, then plans and metering. The assessment shows what can be kept.
Does subscription billing come into this?
Plans and metering sit here. Billing itself, with cycles and failed payments, is the recurring billing service.
What if a large customer demands a database of its own?
A database just for that customer, in the required cloud region, is one of the options in the model. This is decided before development, not after.
Write to Balkan
Talk to us about your project