Multi-tenancy means one application serves many customers, and each customer’s data stays invisible to the others. The main risk is a leak between tenants. We design against that in the database itself, not only in the screens.
What does a multi-tenant SaaS need?
A SaaS product is more than an app with a login page. These are the parts we plan from the start.
- Tenants and users, with roles and invitations.
- Data isolation between tenants.
- Background jobs for work that should not block a page.
- File storage for uploads and generated documents.
- Billing and subscriptions.
- Hosting, backups and monitoring.
How do we keep each customer’s data separate?
The common approach filters every query by a tenant id in the application code. It works until one query forgets the filter. That is a data leak, and it is easy to write by accident.
We add a second layer. In Forkly and Mesito the database enforces isolation with PostgreSQL row-level security. Each request tells the database which tenant it acts for. The database then returns only that tenant’s rows, even if a query is wrong.
This is true of Forkly and Mesito only. Kommo is a marketplace with a different data model, and we make no such claim for it.
| Approach | Strength | Cost |
|---|---|---|
| Filter by tenant in code only | Simple | One missed filter leaks data |
| Shared database with row-level security | Strong, and cheap to run | Needs careful design and tests |
| A separate database per tenant | Strongest separation | More to run, update and back up |
For most business platforms the middle option is the right balance. If you have a customer with strict contractual needs, we can discuss the third.
How do background jobs work?
Emails, imports, notifications and reports run in workers, outside the web request. Our products use queues on PostgreSQL (pg-boss) or Redis (BullMQ). Scheduled jobs are written so that two copies running at once do nothing twice, which matters the day a second server is added.
Where do files go?
Uploads, documents and generated PDFs go to S3-compatible object storage, not to the application server’s disk. The same code works with Garage today and could work with another S3 provider by changing configuration. Kommo also runs a video processing pipeline on top of this.
What about billing and subscriptions?
Forkly has subscriptions and invoicing built in, so the product itself handles recurring plans and invoices. Billing is where requirements vary most: plans, trials, tax rules, invoice formats and the payment provider. We agree these in the design stage, before any code.
How do we host and monitor it?
We run our own products in containers, with automated backups and monitoring, and we offer the same for client platforms. Images are built once and deployed by version, so a release can be rolled back.
Forkly is a public preview with demo venues, not a launched product. We say that on its page.
Where to go next
See the wider software service or the web applications side of the same work. To talk about a platform, contact us.