Single-tenant vs multi-tenant SaaS: why construction software should be single-tenant
Most modern SaaS is multi-tenant: one database, one schema, your data sits alongside everyone else's, separated by a tenant_id column. For construction procurement, that's the wrong default.
The standard model
Multi-tenant means: one big PostgreSQL cluster, every table has a tenant_id column, every query says WHERE tenant_id = ?. It's how Slack, Notion, Linear and most modern B2B SaaS work. It's cheap: one database instance amortises across thousands of customers. It scales beautifully.
The trade-off: every customer's data lives next to every other customer's data. A query bug that forgets the WHERE clause leaks. A backup restoration that touches the wrong rows leaks. A subpoena against one customer can — in theory — drag in evidence from another.
Why construction is different
In office spend, the data is boring: laptops, SaaS subscriptions, the lunch tab. Nobody loses sleep if a competitor sees how much you spent on Notion last quarter.
In construction procurement, the data is your competitive position:
- The price your supplier gives you vs your competitor.
- The margin on your last tender for the same building type.
- The crew rates you pay vs the market.
- Variation orders that reveal where your project bled money.
If you and your direct competitor both use the same multi-tenant procurement SaaS, all of that data sits in one database. The vendor's analytics team may not look — but they could. Many vendor T&Cs explicitly allow aggregate "industry benchmarks" derived from customer data. If your prices feed those benchmarks, you've trained the benchmark your competitor sees.
The single-tenant alternative
Single-tenant means each customer gets a dedicated database. Same software, same code, but no shared row space. Trade-offs:
- Cost: higher per-customer infrastructure. Mitigated by sensible defaults — small Postgres + autoscaling worker.
- Updates: rolling deployments across N instances instead of one. We script it.
- Cross-tenant analytics: impossible by construction. That's a feature for you, not a bug.
For mid-size contractors (under €500M revenue) the cost delta is small enough to absorb into the subscription. We do.
What "your instance" actually means at Operis
- A dedicated PostgreSQL database, EU-hosted.
- Your own subdomain —
your-company.operis.build. - Backups in your own bucket, encrypted with your KMS key on Large tier.
- Full data export to CSV or Parquet, on demand, no contract clause required.
- Zero rows of your data in any shared database. Ever.
"The single-tenant promise is the reason we signed. We've been burned by 'industry benchmarks' before — it's how a former vendor inadvertently coached our competitor on our crane rates."
The honest counter-argument
Multi-tenant SaaS is genuinely better for most software categories. Single-tenant is a deliberate choice for industries where customer data is competitive intelligence. Construction is one. Healthcare is another. Defence is another. If your software doesn't touch competitive data, multi-tenant is fine.
If it does — read the data-processing clauses before you sign. The line about "aggregate industry analytics" is usually short, vague, and very expensive.
If your current vendor stores everyone in one database, you may want to see what dedicated instance looks like.