Control Plane vs. Data Plane: The Cloud-Prem Architecture Behind PlanetScale and Tailscale

• B2B vendors face a structural tradeoff: multi-tenant SaaS is fast to build but carries cross-tenant data risk; pure on-prem is secure but expensive to support.
• Splitting the architecture into a control plane (stays in the vendor’s cloud) and a data plane (runs in the customer’s own cloud account) resolves both problems at once.
• PlanetScale runs its database data plane inside the customer’s AWS or GCP account, connected to its control plane through AWS PrivateLink or GCP Private Service Connect.
• Tailscale keeps device-to-device traffic on direct WireGuard connections; its coordination server only handles identity verification and key distribution – it never touches user data.
• The common thread across both implementations: an encrypted, auditable channel that gives the vendor zero direct access to customer data while still allowing centralized updates and monitoring.
• This pattern – often called Cloud-Prem or BYOC – is becoming the default architecture choice for B2B vendors selling into regulated industries and security-conscious enterprises.

Every B2B infrastructure vendor eventually runs into the same wall: enterprise customers want SaaS-level velocity, but their security teams won’t approve a platform where customer data sits in someone else’s multi-tenant database. The vendor either slows down to satisfy procurement, or ships fast and hopes the security review goes smoothly. Neither option is good, and the tension between the two has shaped a specific architectural pattern that’s worth examining closely.

PlanetScale and Tailscale are two of the clearer public examples of how this gets solved in practice. Both split their systems into a control plane and a data plane, placing the sensitive half of the system inside the customer’s own infrastructure while keeping the management layer centralized. The split isn’t a marketing term – it’s a specific, well-documented architectural decision with real engineering tradeoffs, and it’s worth understanding exactly how it works.

The control plane is the part of a system that makes decisions about how things should work – configuration, routing logic, feature updates, the dashboard and API a customer interacts with.

The data plane is where the actual work happens – where data is stored, processed, or transmitted according to the rules the control plane sets.

In a Cloud-Prem architecture, that distinction becomes a literal infrastructure boundary instead of just a conceptual one. The control plane stays in the vendor’s cloud account, where it can be updated, monitored, and operated centrally. The data plane runs inside the customer’s own AWS account, GCP project, or on-prem environment – physically separated from the vendor’s infrastructure and from every other customer’s data.

The terminology has roots in networking, where routers and switches have long separated the control plane (routing protocols, decision-making) from the data plane (actual packet forwarding). Software-defined networking (SDN) made that separation explicit and programmable. SaaS and cloud infrastructure vendors borrowed the same mental model and applied it to a different problem: not packet forwarding, but customer data isolation.

Classic multi-tenant SaaS architecture pools every customer’s data into shared infrastructure, isolated by application-level logic – row-level permissions, tenant IDs, access control checks scattered through the codebase. It’s fast to build and operate, but the isolation guarantee is only as strong as the code enforcing it. A single bug in a query filter or an authorization check creates the possibility of cross-tenant data exposure, and that risk is exactly what security teams at large enterprises are trained to look for during a vendor review.

The alternative – full on-premises deployment – solves the isolation problem by giving each customer their own dedicated instance of the entire system. But it shifts an enormous operational burden onto the vendor: customers fall behind on version upgrades, configuration drifts from what was tested, and the vendor loses observability into how the system is actually behaving in production. Supporting dozens of slightly different on-prem deployments is its own kind of chaos, just a financial and operational one instead of a security one.

The split-plane approach – sometimes called Cloud-Prem, sometimes BYOC (Bring Your Own Cloud) – sits between these two extremes. The data plane gets the physical isolation of on-prem without the version-drift problem, because the control plane can still push updates and pull telemetry through a defined channel. The vendor keeps centralized operability; the customer keeps physical data isolation. Neither side has to compromise on the thing they care about most.

PlanetScale’s data plane – the actual Vitess database cluster that stores customer data – runs inside the customer’s own AWS sub-account or GCP project, not inside PlanetScale’s infrastructure. The customer owns the compute, the storage, and the network boundary around their database.

PlanetScale’s control plane – the dashboard, the API, the logic that handles schema changes, backups, and scaling decisions – stays in PlanetScale’s own cloud environment. According to PlanetScale’s own documentation, the two sides communicate through a private, non-public network path: AWS PrivateLink when the customer is on AWS, or GCP Private Service Connect on Google Cloud. Traffic between the control plane and the customer’s data plane never crosses the public internet.

For customers with stricter requirements, PlanetScale also supports customer-managed encryption keys (CMK), so the customer retains direct control over the cryptographic keys protecting their own data – rather than trusting PlanetScale’s key management exclusively. The combination of account-level isolation, private network connectivity, and optional customer-held keys is what lets PlanetScale tell enterprise security teams that the vendor has no direct path into the customer’s database.

Tailscale’s implementation looks different on the surface because the product itself is different – a mesh VPN connecting a customer’s own devices – but the underlying principle is identical. The data plane in Tailscale’s case is the actual encrypted traffic between a customer’s devices, carried over direct WireGuard connections. That traffic is end-to-end encrypted and travels directly between the two communicating devices whenever a direct path is available – it does not route through Tailscale’s servers.

Tailscale’s control plane is the coordination server: it verifies device identity, validates public keys, and distributes the key material devices need to establish those direct WireGuard connections with each other. Per Tailscale’s own architecture documentation, the coordination server explicitly does not see or relay the actual data traffic between devices – its job is limited to identity and key distribution, not data transport.

To prevent a compromised or spoofed coordination server from silently hijacking key distribution, client devices verify the control plane’s identity using a TLS-pinned certificate before trusting any key material it sends. That pinning step closes a specific attack surface: even if an attacker could intercept traffic to the coordination server, a device wouldn’t accept keys from anything other than the certificate it was configured to trust.

PlanetScale and Tailscale solve fairly different problems – one is a managed database, the other is a mesh network – and their specific mechanisms reflect that: AWS PrivateLink and CMK encryption on one side, WireGuard and TLS-pinned certificates on the other. But underneath the different mechanisms, the architectural principle is the same.

In both cases, the vendor builds a connection that is encrypted, narrowly scoped, and structured so the vendor never gets unrestricted access to the customer’s actual data. PlanetScale’s control plane can issue commands and pull metrics through PrivateLink, but it doesn’t have a standing credential that lets it read arbitrary rows out of the customer’s database. Tailscale’s coordination server can distribute keys, but it has no mechanism to decrypt or relay the WireGuard traffic those keys protect.

That narrow scoping is what makes the architecture auditable from the customer’s side. A security team reviewing either vendor’s access model can point to a specific, bounded channel – not a blanket trust relationship – and verify exactly what crosses it. That’s a fundamentally different conversation than the one security teams have with a typical multi-tenant SaaS vendor, where the honest answer to ‘what can you access’ is closer to ‘everything, governed by application code we don’t let you inspect.’

On the isolation side, splitting the planes solves the structural weakness of multi-tenant SaaS. Each customer’s data plane runs in its own account or environment – there’s no shared database, no shared compute, no application-level filter standing between one customer’s data and another’s. The isolation is physical and infrastructural, not just a logic check that could have a bug in it.

On the operability side, it solves the chaos that makes pure on-prem deployments expensive to support. Because the control plane stays centralized, the vendor can push configuration updates, roll out new features, and pull operational telemetry through the same defined channel used for everything else – without needing physical or remote access to every customer’s individual deployment. Version drift across customers becomes much less likely when updates flow through one consistent mechanism instead of depending on each customer’s IT team to apply patches on their own schedule.

For companies selling into large enterprises, this architecture changes what a security review actually has to evaluate. Instead of asking a vendor’s security team to trust a black-box multi-tenant system, the customer’s own security team can audit a specific, scoped channel between their environment and the vendor’s. That’s a faster, more concrete conversation – and in practice it shortens the security review cycle that often sits between a signed contract and an actual deployment.

For the vendor’s engineering organisation, the split also changes the cost structure of growth. A startup or lean team doesn’t have to provision, secure, and operate the full infrastructure stack underneath every customer – the data plane runs on infrastructure the customer is already paying for and already operating inside their own cloud account. That keeps the vendor’s own cloud bill and operational surface area smaller, which matters directly to margin in an infrastructure business.

Building a Cloud-Prem or BYOC architecture correctly touches almost every part of the infrastructure stack: the CI/CD pipeline that ships updates to a control plane without ever touching customer environments directly, the container orchestration that runs consistently whether the data plane lands in a customer’s AWS account or their own Kubernetes cluster, and the private networking layer that has to be provisioned and secured per customer rather than once.

AppRecode works with B2B platforms on exactly this kind of architecture decision. Relevant services include DevOps Consulting for teams evaluating whether a split-plane model fits their product, DevOps Development for building the control plane and deployment automation itself, and CI/CD Consulting for designing pipelines that can ship updates safely into infrastructure the vendor doesn’t directly control.

On the data plane side, Kubernetes Consulting and Container Orchestration Consulting help teams design deployment patterns that behave consistently whether they land in a customer’s cloud account or on their own infrastructure. Cloud Infrastructure Management Services cover the ongoing operational side once the split architecture is live – monitoring, scaling, and keeping the control-to-data-plane channel healthy across every customer environment.

For teams that want the Kubernetes side of this in more technical depth, our earlier piece on Kubernetes architecture, components, and communication flow covers how control-plane and node-level communication works inside a cluster – the same conceptual split discussed here, one layer down.

The control plane / data plane split isn’t a workaround or a compliance checkbox – it’s a direct architectural answer to a conflict that every infrastructure vendor selling into enterprise eventually faces. PlanetScale and Tailscale arrived at structurally similar solutions from very different starting points, which suggests the pattern is closer to a sound engineering default than a coincidence.

The pressure pushing more vendors toward this model is only going to increase. AI infrastructure startups handling proprietary training data, and vendors selling into healthcare, finance, and government, are exactly the customers least willing to accept a black-box multi-tenant trust model – and exactly the customers most likely to ask, during procurement, whether a vendor supports running the data plane inside their own cloud account.

Teams building B2B infrastructure products today are increasingly treating this split as a default design decision made early, rather than a retrofit applied after the first enterprise deal stalls in security review.

When people say control plane, I hear “the part where the operator changes the rules.” It is the dashboard, API, policy layer, scheduler, identity logic, or update service that tells the rest of the system what to do.
It does not have to carry the customer’s data to matter. In fact, it can be extremely powerful without touching rows or packets directly. If it can change who has access, ship a new version, rotate keys, or point traffic somewhere else, security teams should care about it.
That is why split-plane architecture is not just a vocabulary lesson. In a Cloud-Prem product, the vendor often keeps this layer central so it can support customers and ship updates. That can be good.
But I would always ask what the control plane is allowed to do. Can it read data? Can it write config? Can it trigger a deploy? Can customers approve or block changes? The answers matter more than the label.

The data plane is where the real work happens. It is the part that stores records, moves packets, serves requests, runs jobs, or processes customer traffic. If the control plane gives the order, the data plane carries it out.
In a network, routing decisions are control-plane work. Packet forwarding is data-plane work. In a database service, the dashboard and branch controls may live in the control plane, while the database cluster that holds customer data is the data plane.
Cloud-Prem and BYOC products use that split as a boundary. The data plane can run in the customer’s account, VPC, project, or cluster instead of sitting beside every other customer in the vendor’s shared environment.
That does not make it magically safe. The data plane still needs backups, patching, monitoring, encryption, access control, and incident handling. It also needs a limited channel back to the control plane. If that channel is too broad, the split is mostly theater.

Cloud-Prem is the middle ground between SaaS and old-school on-prem. The vendor keeps the management side in its cloud, but the sensitive runtime sits in the customer’s environment or cloud account.
That matters because enterprise buyers often want two things that pull against each other. They want SaaS speed: updates, support, monitoring, and a product that keeps improving. They also want stronger control over data, networks, keys, and compliance boundaries.
A split model tries to give both sides something useful. The vendor operates one central control plane. The customer gets a separate data plane, often in AWS, Google Cloud, Azure, Kubernetes, or private infrastructure.
I would still ask hard questions before trusting the label. What data crosses the connection? Who owns the cloud account? Can the vendor query production data? Are changes logged? What happens during an outage? Cloud-Prem is useful only when the boundary is real, not just drawn nicely in a diagram.

I would treat Cloud-Prem and BYOC as cousins, not as perfectly fixed terms. In many sales calls they mean almost the same thing: the vendor keeps a central service, while the customer runs the sensitive part in their own cloud or infrastructure.
BYOC sounds more literal. Bring your own cloud. The buyer supplies AWS, Azure, Google Cloud, or another approved environment. That can help with data location, network controls, internal billing, and security review.
Cloud-Prem is a little broader. It says the product still feels cloud-operated, but the data plane sits closer to the customer’s control. Sometimes that means public cloud. Sometimes private cloud. Sometimes real on-prem.
I would not trust either label by itself. Ask for the actual diagram, IAM model, network path, upgrade process, support access, and exit plan. Two vendors can use the same acronym and give customers very different control in practice. That is where risk hides.

PlanetScale and Tailscale separate the planes because their customers need convenience and isolation at the same time. That is the core tension. Enterprises like SaaS speed, but they also ask hard questions about where sensitive data sits, who can access it, and what happens if one tenant is isolated only by application logic.
PlanetScale’s case is about database infrastructure. The management layer can stay centralized, while the customer’s database runtime can be isolated through managed or private-connectivity models, depending on the plan and cloud setup. That helps reduce the feeling of a shared black-box database service.
Tailscale’s case is network traffic. Its coordination service handles identity, keys, policies, device discovery, and connection coordination. The actual data plane is encrypted WireGuard traffic between devices, directly when possible and through DERP relays when direct paths do not work.
The same idea shows up in both products: keep the operating experience centralized, but avoid putting all sensitive customer data or traffic inside the vendor’s ordinary multi-tenant runtime.

It can be more secure for a specific reason: the customer’s data plane can be physically or logically isolated instead of sharing the same runtime with every other customer. That reduces the risk of a bug in tenant filtering exposing one customer’s data to another.
But I would not call it automatically safer. The split only helps if the boundary is designed well. The control plane should have limited permissions, narrow network access, strong identity, audit logs, safe update mechanisms, and clear rules for emergency access. The data plane still needs normal security work: patching, secrets management, encryption, monitoring, backups, and incident response.
There is also a new risk. If the control plane can push code or configuration into many customer environments, a compromise there may have a wide blast radius. The architecture reduces one class of risk but creates a different trust surface.
So the honest answer is conditional. Compared with basic multi-tenant SaaS, a split plane can give enterprise buyers a clearer isolation story. It does not replace vendor security review. It makes the review more concrete.

Buyers should ask where the data plane runs, what the vendor can access, and how that access is technically limited. The answer should be more specific than “your data stays in your cloud.” That sentence sounds good, but it does not explain the trust model.
Start with the boundary. Does the vendor deploy into your account, a vendor-controlled account inside your organization, or a shared provider environment? Who owns the keys? Which network paths exist? Can the vendor open a shell, read storage, query data, or only call a narrow management API?
Then ask about updates. Who approves them? Can they be paused? Are changes signed? Is there a rollback path? If the control plane is down, does the data plane keep serving existing traffic?
Logging and evidence matter too. Security teams need audit logs, IAM policies, network diagrams, data-flow diagrams, incident procedures, and a clean exit plan.
The best vendors can explain this without hiding behind diagrams. If the team cannot describe the channel and its limits plainly, the architecture probably needs more work.

It depends on what the data plane can do without fresh instructions. A well-designed split-plane system should keep existing data-plane work running for at least some time. Existing traffic, cached policy, local keys, and already-deployed services should not stop only because the dashboard is unavailable.
Tailscale is a useful example. Its documentation says existing connections and cached policies can continue if the coordination server is unavailable, but new devices, key refreshes, policy changes, and some new connection setup will be affected. That is exactly the kind of tradeoff buyers should understand.
For a database or application platform, the answer may be different. The data plane may keep serving reads and writes, while provisioning, scaling, backup configuration, schema workflows, or observability updates are delayed. Or it may depend heavily on the vendor’s control plane for too many actions.
I would ask vendors to document degraded mode. What still works? What fails? For how long? What alerts fire? Who can operate locally? A control-plane outage should be annoying, not mysterious.

I would not build split-plane architecture as a fashion move. Build it when customers are already telling you ordinary SaaS is not enough. The signs are usually blunt: “Can this run in our cloud?”, “Can we keep the keys?”, “Can traffic stay private?”, “Can we avoid shared runtime?”
That pressure shows up a lot in databases, security tools, AI platforms, developer infrastructure, healthcare, finance, and government software. For those buyers, the architecture can turn a vague trust conversation into a review of a specific boundary.
Still, the bill is real. You now support customer accounts, private networking, upgrades across different environments, limited telemetry, weird IAM setups, and failures you cannot always see directly.
So I would start with the trust model, not the code. Write what stays central, what runs with the customer, what crosses the channel, and what the vendor cannot do even on a bad day. If that page is unclear, the product is not ready.