A practical breakdown of the four ways SaaS gets delivered today, with a comparison matrix and scenario-based recommendations for teams choosing what to ship or buy.

Most SaaS pricing pages don't tell you where your data actually lives.

That's by design. For years the default answer was "our cloud, our region, trust us."

That default is breaking down. GDPR fines, the US CLOUD Act, sectoral data residency laws in India, Saudi Arabia, and Australia, and enterprise buyers who now write deployment-model requirements into RFPs have all pushed SaaS vendors to offer more than one way to ship the same product.

If you're a product or engineering leader deciding how to deliver your software (or an enterprise buyer deciding what to require from a vendor) the deployment model matters as much as the feature set. It determines who owns the data, who patches the servers, who gets called at 3am, and how fast you can ship changes.

This guide compares the four models you'll actually encounter: multi-tenant SaaS, single-tenant SaaS, bring-your-own-cloud (BYOC), and self-hosted. It's vendor-neutral, and there is no "right" answer.

There are tradeoffs, and the right one depends on what you're optimizing for.

The four deployment models, defined

Multi-tenant SaaS

One application, one database (or one logically partitioned database), many customers. Everyone shares the same infrastructure, and tenant isolation happens in software, typically through a tenant_id column, row-level security policies, or namespaced schemas. The vendor operates everything.

This is what most people mean when they say "SaaS." Salesforce, Slack, Notion, Linear: all multi-tenant.

Single-tenant SaaS

The vendor still operates the infrastructure, but each customer gets their own isolated stack. Separate database, separate application instances, separate encryption keys, often a separate VPC. The vendor's cloud account, the customer's dedicated resources.

You'll see this offered as an "enterprise" or "dedicated" tier. It's typically the same product, but with dedicated infrastructure and a higher price tag to go along with it.

Bring-your-own-cloud (BYOC)

The vendor's application runs inside the customer's cloud account (AWS, GCP, Azure). The customer owns the compute, storage, and network. The vendor gets a scoped IAM role to deploy, monitor, and upgrade the software. Data never leaves the customer's environment.

BYOC is the fastest-growing category in enterprise SaaS. Snowflake, Databricks, Confluent, MongoDB Atlas, and a wave of AI infrastructure vendors have moved this direction because it lets them serve regulated buyers without operating regulated infrastructure themselves.

Self-hosted

The vendor ships software, but the customer runs it.

No vendor access, no managed control plane, no phone home unless explicitly configured. This can be commercial (a license and a support contract) or open source (GitLab CE, MinIO, PostgreSQL). The customer is fully responsible for the operational lifecycle.

Comparison matrix

How to compare across the dimensions that actually matter

Data residency and sovereignty

Multi-tenant SaaS almost always stores data in the vendor's cloud and in the vendor's region of choice. Some vendors offer regional pinning (EU-only, US-only), but the control plane usually still runs in a single jurisdiction, most often the United States.

That's the part enterprise legal teams keep flagging: even if your customer data sits in Frankfurt, if the vendor's coordination server is on AWS us-east, US law can compel disclosure.

Single-tenant SaaS reduces the risk but doesn't eliminate it. The infrastructure is dedicated, but the vendor still operates it, so the same jurisdictional questions apply.

BYOC solves the residency problem cleanly. The data plane runs in the customer's account, in a region the customer chooses. The vendor typically retains a metadata channel (license validation, telemetry, sometimes a control plane) but the actual customer data never leaves the customer's cloud.

Self-hosted is the strongest position for data sovereignty. It's also the most expensive to maintain that position, because you're now operating the software.

Security and compliance

Multi-tenant is great for most SOC 2 and ISO 27001 audits. It gets harder for HIPAA (BAA required, some vendors won't sign one on lower tiers), PCI-DSS (scope creep is common), and FedRAMP (multi-tenant environments rarely achieve High).

The architectural difference that matters for security is blast radius. In multi-tenant, a bug in a tenant-isolation query — a missing WHERE tenant_id = ? clause, essentially — can leak data across every customer. It's happened publicly multiple times. Single-tenant and BYOC both isolate that risk to a single customer's environment.

For regulated buyers, the deployment model is often the differentiator that gets a vendor onto the shortlist, before any feature comparison happens.

Total cost of ownership

Multi-tenant is cheapest per seat because the vendor amortizes infrastructure across the entire customer base. This is why free tiers and low-cost SMB pricing almost always run on multi-tenant infrastructure.

Single-tenant costs 2–5x more per seat, sometimes more. You're paying for dedicated resources that mostly sit idle.

BYOC has a different cost curve. The vendor charges a license fee, and the customer pays their own cloud bill. At small scale this often costs more than multi-tenant SaaS because you're not amortizing infrastructure. At large scale, think 500+ engineers, terabytes of data, BYOC frequently comes out cheaper, because you're paying wholesale cloud prices instead of the vendor's markup, and you can use existing committed spend and reserved instances.

Self-hosted has the lowest license cost (often zero for open source) and the highest operational cost. Salary for people who run it, on-call rotations, upgrade planning, security patching, incident response. If you don't have those people already, self-hosted is not actually cheaper.

Upgrade velocity

Multi-tenant vendors ship continuously. New features appear without customer action, sometimes without warning. This is great for the vendor's roadmap velocity and occasionally bad for enterprise customers who have change-management processes.

Single-tenant sometimes staggers rollouts. The vendor pushes new versions to smaller customers first, then to enterprise tenants after a validation window.

BYOC is the interesting middle ground. The vendor pushes updates, but the customer usually has a control gate: a maintenance window, a version pin, a staging environment. Upgrade velocity slows to something the customer can manage.

Self-hosted upgrade velocity depends entirely on the customer. Some run bleeding-edge, most run six to twelve months behind. This is why self-hosted deployments accumulate CVEs.

Operational burden

The tradeoff is straightforward: the closer the software runs to the customer, the more the customer operates.

• Multi-tenant SaaS: customer operates nothing.

• Single-tenant SaaS: customer operates nothing, but often pays for a customer success manager.

• BYOC: customer operates the cloud account, IAM, networking, and enough monitoring to know when

• things break. Vendor operates the application inside that environment.

• Self-hosted: customer operates everything.

If your team is small, this dimension often decides the model.

Time-to-value

• Multi-tenant: sign up, get a URL, invite users. Minutes.

• Single-tenant: sign contract, vendor provisions dedicated stack. Hours to days.

• BYOC: customer provisions cloud account, sets up IAM roles, vendor deploys application. Days to weeks depending on procurement.

• Self-hosted: everything from infrastructure design onward. Weeks to months.

  
  

When to choose each model

Multi-tenant SaaS

Choose this when:

• You're an early-stage startup and speed matters more than isolation.

• Your data is not sensitive enough to attract compliance scrutiny.

• You have no full-time infrastructure engineer.

• You want to be up in an afternoon.

Avoid this when:

• You're in a regulated industry with strict data residency requirements.

• Your buyers are demanding proof of tenant isolation.

• You've been through a shared-infrastructure incident and your board has feelings about it.

  
  

Single-tenant SaaS

Choose this when:

• You want a managed experience but need isolated infrastructure.

• You have HIPAA, PCI, or similar compliance requirements and the vendor's multi-tenant tier can't support them.

• You're a mid-market or enterprise buyer with a modest budget for premium tiers.

Avoid this when:

• Your compliance requirements specify that data must reside in your infrastructure, not the vendor's.

• The price delta versus multi-tenant is more than the isolation is worth.

  
  

BYOC

Choose this when:

• You're an enterprise buyer with data residency requirements the vendor can't meet in their cloud.

• You have significant committed cloud spend and want to use it.

• You need vendor-managed software but customer-owned data.

• You're a vendor building for regulated industries where "trust us with your data" isn't a viable sales motion.

Avoid this when:

• You don't have the cloud engineering capability to manage the customer side of the arrangement.

• Your volume is small enough that BYOC economics don't work.

• The vendor's BYOC offering is early and the operational model is still maturing.

  
  

Self-hosted

Choose this when:

• You have air-gap requirements or operate in classified environments.

• You need full control over the upgrade cadence.

• You have (or are willing to hire) the operations team to run it.

• The software is genuinely commodity and the vendor doesn't add enough value to justify the ongoing license.

Avoid this when:

• You don't have on-call coverage for the system.

• The software is complex enough that operating it is a full-time job you weren't planning to staff.

• You'd rather be building your product than patching someone else's.

  
  

What migrating from multi-tenant to BYOC actually looks like

This is the migration that keeps coming up in 2025 and 2026, so it's worth being specific about what it involves.

The typical trigger is a regulated buyer — often in EU financial services, healthcare, or public sector — telling the vendor "we can't put our data in your cloud." The vendor either loses the deal, offers self-hosted (which most modern SaaS companies are not architected to support), or builds BYOC.

The engineering work is substantial:

1. Separate control plane from data plane. In multi-tenant, these usually run in the same VPC. For BYOC, the control plane stays with the vendor; the data plane has to run standalone in the customer's cloud. This typically requires rearchitecting how the application authenticates, receives configuration, and reports telemetry.

2. Build a deployment substrate. Terraform modules, Helm charts, or Kubernetes operators that can install and upgrade the software in a customer's cloud with minimal customer involvement. Most vendors underestimate this. It's a small platform team's worth of work.

3. Design the metadata channel. The vendor still needs to know the software is running, licensed, and healthy. What flows over that channel — and what doesn't — is both a security question and a sales question. Customers will ask.

4. Rethink the support model. Support engineers no longer have direct database access. Incident response requires customer cooperation. Runbooks change. SLAs get renegotiated.

5. Rebuild the billing model. Consumption-based billing in a multi-tenant environment is straightforward. In BYOC, the vendor no longer has direct visibility into every resource, so metering has to be built explicitly and validated.

6. Update the security posture. The vendor's IAM role in the customer's account is now a security boundary the customer will scrutinize. Least-privilege access, credential rotation, and audit logging all become customer-facing artifacts, not internal ones.

For customers moving from multi-tenant to BYOC, the migration usually looks like a data export, a fresh install in the customer cloud, and a validation period where both environments run in parallel. Vendors have gotten better at automating this, but "seamless migration" is rare in practice — expect a project, not a config change.

A note on network access as a deployment concern

One thing worth flagging: whichever model you choose, someone still has to reach the application to administer it. For multi-tenant SaaS, that's the vendor's problem. For single-tenant, BYOC, and self-hosted, it becomes yours.

The old answer was to put the admin plane behind a VPN. That answer has aged badly. VPNs expose inbound ports, grant broad network access once a user is authenticated, and make least-privilege enforcement nearly impossible at the application level.

Twingate's approach is to treat each administrative resource as its own access-controlled endpoint. Connectors sit inside the customer's environment (whether that's a BYOC deployment, a self-hosted stack, or a single-tenant cloud) and make outbound-only connections. No inbound firewall rules. Access is granted per-resource, per-user, per-device, with the Controller and Connector independently verifying each request. It's the same architecture whether the resource lives in AWS, on-prem, or in a homelab — which happens to line up neatly with the "software should run where the data is" logic behind BYOC in the first place.

Closing

There's no universally correct deployment model. There's the one that matches your compliance posture, your team's operational capacity, your growth stage, and the buyers you're trying to close. Multi-tenant is right for a lot of teams, especially early. BYOC is right for a growing share of the enterprise market. Self-hosted still has its place, though it's a smaller place than it used to be.

For more details on how Twingate deploys in each of these environments, see the Twingate documentation.

New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.