Multi-tenancy ready without overengineering
Prepare data access for a future operation with multiple companies and branches, without turning the MVP into an overbuilt solution when it initially runs with a single company and a single branch.
Last updated: 2026-09-18 · Owner: Flexora engineering team
Alternatives considered
- Discarded
- Assume persistence always maps to a single database.
- Chosen
- Prepare the persistence layer so that assumption never gets baked into the code.
Decision made
Centralize data access through a tenant context. The MVP uses a shared database, but the code doesn't depend on that condition. The hierarchy considered is tenant, company, branch, and location.
Rationale
Lets development start with the initial scope while keeping a growth path toward multi-company and multi-branch operation without a later rewrite.
Frequently asked questions
- What did Pymerce decide about "multi-tenancy ready without overengineering"?
- Centralize data access through a tenant context. The MVP uses a shared database, but the code doesn't depend on that condition. The hierarchy considered is tenant, company, branch, and location.
- What's the difference between single-tenant and multi-tenant, and why did Pymerce go with this hierarchy?
- Single-tenant isolates each client in its own database or infrastructure; multi-tenant shares resources across clients with logical isolation. Pymerce defines a tenant, company, branch, and location hierarchy, and always resolves data access through the tenant — even though the MVP runs on a single shared database.
- Should each client get their own database, or is it fine to share one?
- For Pymerce's initial scope, sharing one database is enough and simpler to run. The key decision isn't the database itself — it's that the code never assumes that setup. Access always goes through the tenant context, so moving to separate databases later doesn't mean rewriting the data layer.
- What are the downsides of building for multi-tenancy from the MVP stage?
- It adds a layer of indirection (the tenant context) that isn't needed if the business never grows into multi-company territory. Pymerce keeps that cost contained by centralizing data access in a single point in the code, instead of building physical isolation or separate infrastructure that isn't needed yet.
This kind of decision applies to your project too
If your operation needs custom software with technical decisions that are documented and built to last, we can help you define them.