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.

The control plane is the part of a system responsible for making decisions about how the system behaves – configuration, routing logic, feature rollout, the management interface a user or administrator interacts with. In a split cloud-prem architecture, it’s the layer that stays inside the vendor’s own infrastructure.

The data plane is where the actual work happens – storing data, processing requests, transmitting traffic – according to the rules the control plane defines. In a Cloud-Prem architecture, the data plane runs inside the customer’s own cloud account or on-premises environment, physically separate from the vendor.

Cloud-Prem is a deployment model where a vendor’s control plane (dashboard, API, update logic) stays centralized in the vendor’s cloud, while the data plane (the part that touches the customer’s actual data) runs inside the customer’s own cloud account or infrastructure. It combines the centralized manageability of SaaS with the physical data isolation usually associated with on-premises software.

In practice, the two terms describe the same architectural pattern and are often used interchangeably. BYOC tends to emphasize that the customer supplies and pays for the underlying cloud account where the data plane runs; Cloud-Prem emphasizes the hybrid nature of the result – cloud-operated, but with data kept where the customer (not the vendor) controls it. Both describe a vendor’s control plane paired with a customer-hosted data plane.

Both companies needed a way to give enterprise customers strong data isolation guarantees without forcing those customers into a slow, hard-to-support fully on-premises deployment. Splitting the architecture lets PlanetScale keep customer databases inside the customer’s own AWS or GCP account while still operating the management layer centrally, and lets Tailscale keep device traffic end-to-end encrypted and direct while still coordinating identity and key distribution from a central service.

It removes a specific class of risk that multi-tenant SaaS carries structurally: cross-tenant data exposure caused by a bug in application-level isolation logic. Because each customer’s data plane is physically separate, that particular failure mode isn’t possible in the same way. It doesn’t make every other security practice – patching, access control, monitoring – automatically better; those still depend on how well the vendor implements the control plane side and the channel connecting the two.