Multi-tenant vs single-tenant
field service software — an operator's view.

Most field service software is sold to you without anyone explaining how your data is actually stored. The sales deck talks about features. Maybe security. Almost never architecture. But the choice between multi-tenant and single-tenant under the hood determines what happens to your data when there's a bug, what kind of customization you can ask for, and what your exit looks like when you eventually leave.

This is the post I wish someone had written when I was shopping for field service software before I gave up and built my own. I'm going to skip the marketing version and get to what actually matters for an oilfield operator.

The short version

Multi-tenant SaaS: many customers, one application, one database, separated by permissions. Cheaper, faster to ship updates, more dependent on the vendor not making mistakes. Single-tenant: each customer gets their own instance and usually their own database. Costs more, ships updates slower per-customer, more isolation when something goes wrong.

Both can work. The right one for you depends on three questions: how sensitive is your data, how custom is your workflow, and how much do you care about lock-in.

What multi-tenant actually looks like

Picture a Postgres database with a "tenants" table. Every other table — work_orders, customers, inventory, photos — has a tenant_id column. When you log in, the application checks your user's tenant_id and adds a "WHERE tenant_id = X" to every query. That's the entire separation between you and the operator down the road who's also a customer.

When it works, it works. The vendor only has to patch one codebase, one database, one set of servers. Costs are spread across thousands of customers. Updates ship to everyone at once. The vendor's per-customer cost is low, so they can charge $99/month and make money.

When it doesn't work, it breaks for everyone. A single bug in the permissions logic — a missing WHERE clause, a typo in a join — and customer A starts seeing customer B's data. This has happened to large, well-funded SaaS vendors more than once. The blast radius is the entire customer base.

What single-tenant actually looks like

Each customer gets their own deployment. Their own database. Sometimes their own subdomain. The vendor patches each instance separately. Customizations can be made per-customer because the customer's instance is theirs to modify.

Costs are higher per customer because the vendor can't share infrastructure as efficiently. Updates take longer to roll out because each instance is patched in sequence. A bad release that takes down one instance doesn't take down the others — the blast radius is one customer at a time.

For sensitive industries — healthcare, finance, defense — single-tenant is usually mandatory because the data isolation is required by regulation. For oilfield, it's not mandatory, but the same logic applies: your well locations, your customer routes, your pricing — none of it should be one bad WHERE clause away from a competitor.

The decision table

Factor	Multi-tenant	Single-tenant
Per-customer cost	Low ($50-200/mo)	Higher ($300-2000/mo)
Update speed	Instant for all	Per-instance, slower
Customization	Generic, configurable	Code-level if needed
Data isolation	Logical (permissions)	Physical (separate DB)
Blast radius of bug	All customers	One customer
Vendor lock-in	High (shared schema)	Lower (own DB exportable)
Compliance posture	Vendor's responsibility	Per-customer evidence

Why oilfield is different from residential service

If you run an HVAC business serving homeowners, your data isn't particularly sensitive. Customer name, address, what you fixed, what you charged. Mildly competitive but nothing earth-shaking. Multi-tenant SaaS is fine for that.

If you run an oilfield service business, your data includes:

• Well locations. Some operators want these confidential. New wells especially.
• Production schedules. When you service which battery tells competitors when production is happening.
• Customer pricing. Your contract rates with E&P companies are commercially sensitive.
• Route data. Where your trucks are, when, builds a competitive picture.
• Compliance records. EPA inspections, OOOOa data, LDAR logs. You don't want this shared with the wrong party.

None of this is national-security data. But it's commercially competitive enough that you should care whether a buggy permissions check could leak it to another operator running on the same SaaS instance.

The customization question

Multi-tenant systems have to be generic. They can't add a field to one customer's work order schema without potentially affecting all customers. So they give you "configurable" — pre-built fields you can show/hide, label, validate. If your workflow doesn't fit the configurable options, you get told "that's not how the software works."

Single-tenant systems can be modified per-customer. Want a custom field for "thief hatch torque spec" because your insurer requires it? In a single-tenant deployment, the vendor can add it for you in a couple days. In a multi-tenant deployment, it either becomes a feature request that takes 18 months, or it gets shoved into a "custom fields" generic that's never quite right.

For an oilfield operator, the custom field problem is real. Every operator has 2-5 fields that are particular to how they run things. A truly fitted-to-you system can hold those. A multi-tenant system makes you adapt your business to the software's defaults.

The lock-in question

Eventually you're going to leave your current software vendor. Either they get acquired, or they raise prices, or your business changes and they don't keep up. When you leave, you want your data with you. All of it. In a format you can use.

Multi-tenant SaaS exports tend to be CSV dumps of the visible fields. You don't get the schema, you don't get the relationships, you don't get the audit logs unless they decide to give them to you. You're paying to leave with less than you came with.

Single-tenant deployments often let you export the entire database. Schema, relationships, audit history. You can import into the next system without losing the history. This is one of the underrated arguments for single-tenant — it's not just about isolation, it's about the optionality of your exit.

How ReliableTrack is built

ReliableTrack is single-tenant by design. Every customer gets their own deployment, their own database, their own subdomain. When I build a custom feature for one customer, it doesn't touch another customer's data because the customer's data is in a different database on different infrastructure.

This costs me more to run than a multi-tenant approach would. I have to update each instance separately. I can't ship a new feature to "all customers" in one deploy. But for oilfield operators with sensitive data and particular workflows, the tradeoff is worth it. I'd rather charge more per customer and have each customer's data and customizations safely isolated than charge less and inherit the blast radius of any bug I ship.

The 48-hour custom build promise depends on this architecture. I can't promise to tailor your work order schema in a multi-tenant system because changing the schema for you would risk every other customer. In a single-tenant system, I can modify your instance independently.

The questions to ask any vendor

If you're shopping for field service software, here are the architecture questions to ask. The vendor's answers will tell you which model you're getting:

1. "Is each customer's data in a separate database or a shared one?" Single answer "separate" = single-tenant. "Logically separated by tenant_id" = multi-tenant.
2. "What's your blast radius for a permissions bug?" Single-tenant vendors should say "one customer." Multi-tenant vendors should be able to explain their isolation controls in detail.
3. "Can I get a full database export, including schema and audit logs, on demand?" Single-tenant: usually yes. Multi-tenant: usually no.
4. "How long does it take to add a custom field that only my company uses?" Single-tenant: hours to days. Multi-tenant: months, if ever.
5. "What's your update cadence per customer?" Single-tenant: lower, more controlled. Multi-tenant: everyone gets every update.

What I'd buy if I weren't building it

If I were back in the position of needing field service software and ReliableTrack didn't exist, I'd pay more for single-tenant. The isolation, the customization room, the data portability — all three matter more in oilfield than the per-month cost difference. I'd be willing to pay 3-4x the multi-tenant price for those properties.

What I would not do is buy a multi-tenant system and pretend the customization story is going to work out. It won't. The architecture is the limit, not the salesperson's promises.