What Are Management, Control, and Data Planes?

Every data or AI platform does two kinds of work. It answers requests: SQL queries, vector searches, model calls, and the tool calls that AI agents make. It also changes itself: it adds datasets, upgrades versions, rotates credentials, and adds capacity.

Platform designers separate these two kinds of work into planes. A plane is a group of components with one job, its own callers, and its own failure behavior. Most platforms have three:

• The data plane executes requests and moves data.
• The control plane keeps the running system in its intended state.
• The management plane is where people and automation define that state and see the results.

The terms come from network engineering. In a router, the forwarding plane (also called the data plane) moves packets, and the control plane computes routes. The management plane configures and monitors the device. RFC 7426 defines these planes for software-defined networks. It notes that a control plane reacts in milliseconds, but a management plane works over minutes, hours, or days.

Cloud services, Kubernetes, and service meshes later applied the same division to software platforms. It matters for data and AI platforms because each plane carries a different risk. The data plane holds customer data and works inside tight latency budgets. The other two planes hold change and governance.

What Does Each Plane Do?

The data plane

The data plane does the work that users, applications, and agents ask for. In a data platform, it parses and runs SQL queries. It reads source systems through SQL federation, and it reads local accelerated copies of frequently used datasets. In an AI platform, it also runs vector and full-text search, embedding generation, LLM inference, and agent tool calls.

Ingestion belongs to the data plane too. A change data capture stream or a scheduled refresh reads and writes customer rows. Configuration can set the schedule, but the data plane moves the data.

Data plane components sit on the request path, so their latency adds to every response. Their load grows with traffic: more agents, queries, or tokens per second need more data plane capacity. They hold the credentials that read source systems, and they apply access policy to each request.

The control plane

The control plane keeps the running system in its intended state. It stores a desired state, observes the actual state, and acts on any difference. This repeated cycle is a reconciliation loop. Typical tasks include:

• Provision compute and storage for new runtimes.
• Deploy configuration and secrets to each runtime.
• Roll out new versions in stages, and roll back a version that fails its checks.
• Add or remove replicas when demand changes.
• Restart failed components and replace unhealthy nodes.

Kubernetes is the most common example. Its API server accepts the desired state and stores it in etcd. Controllers then move the cluster toward that state. An operator is a controller for one application, such as a database or a query engine. It describes that application with custom resources and reconciles them like built-in resources.

The control plane is not on the request path. A query does not wait for a controller to act. Control plane load grows with the number of resources and the rate of change, not with query volume.

The management plane

The management plane is the interface through which people and automation govern the platform. It includes a web console, a management API, a command-line tool, and infrastructure-as-code providers. Teams use it to create projects, invite users, assign roles, and issue API keys.

It also holds policy and records. Teams define which users and agents can query which datasets, and they set quotas. They review usage, costs, dashboards, and audit logs that show who changed what and when.

The management plane writes intent. It does not run workloads. Its callers are people and CI pipelines, so its request rate is low. Its actions carry the most privilege, so they need strong authentication and a complete audit trail.

Vendors draw these lines in different places. Many documents name only two planes and put management functions in the control plane. Microsoft Azure, for example, calls its resource management API the control plane. A three-plane model separates governance from automation, because the two have different users and different risks.

Control Plane vs Data Plane vs Management Plane

The three planes differ in what they answer, who calls them, and what stops when they fail.

The last row explains why the data plane gets the most protection. An outage in the management or control plane stops change, but traffic can continue. An outage in the data plane stops traffic. A well-designed platform therefore keeps every dependency of the request path inside the data plane.

How Do the Three Planes Work Together?

Intent flows down through the planes, and status flows back up. Consider an engineer who adds a dataset for a support agent.

1. The engineer commits the change or submits it in the console.
2. The management plane checks the engineer's role and writes an audit record.
3. The management plane stores the result as a new version of the desired state.
4. The control plane detects the new version and updates runtimes in stages.
5. Each runtime loads the dataset, reads it from the source, and reports ready.
6. Runtimes report health and metrics, which the control plane and the dashboards use.

The support agent's queries never pass through the management or control plane. They go straight to a runtime, which answers from its own configuration and data. The planes above the runtime change what it serves, not the path that each request takes.

Access policy follows the same path. A team writes a rule in the management plane, and the control plane sends it to every runtime. Each runtime enforces the rule on every query, without a call back to the planes above it.

Why Do Platforms Separate the Planes?

Failure isolation and static stability

A data plane that depends only on itself keeps serving when the planes above it fail. It runs with the last configuration it received. Changes stop until the control plane recovers, but queries continue. AWS calls this property static stability.

The opposite design calls the control plane on the request path. For example, a runtime fetches configuration or checks a permission with a central service on every query. That design turns every control plane outage into a data plane outage, and it adds a network round trip to each request.

Kubernetes follows the stable design. Its troubleshooting guide states that existing pods keep working when the API server is down, unless they depend on the Kubernetes API. Static stability has a cost, though. Each runtime keeps a local copy of its configuration and can serve a version that is slightly out of date.

Security boundaries

Each plane needs different access. The data plane holds credentials for source systems and sees rows, documents, and prompts. The control plane needs deployment rights and configuration, but not query results. The management plane needs identities and policy, but not the data itself.

Separate planes apply least privilege at the level of the architecture. A credential for one plane does not grant the access of another. The data plane can also run in a different network or cloud account from the planes that manage it.

Independent scaling and change

Each plane scales with a different input. Data plane capacity follows queries, searches, and tokens per second. Control plane load follows the number of runtimes and the rate of change. Management plane load follows the number of users and projects.

An agent fleet that grows from ten agents to a thousand needs more data plane capacity, not a larger console. Separate planes also release separately. A team can upgrade the control plane without a restart of any runtime. The control plane can then stage a runtime upgrade across the data plane.

Where Does Each Plane Run?

The same three planes appear in every deployment model. The models differ in who operates each plane and where data is processed.

A single process can contain small versions of all three planes. It reads a configuration file, schedules its own work, and serves queries. The file in version control acts as the management plane, and code review acts as its approval step.

BYOC splits the planes across two organizations. The vendor runs the management plane and most of the control plane. The data plane runs in the customer's account, so customer data stays in the customer's network. In a common design, the data plane opens an outbound connection to the vendor, so the customer network accepts no inbound connections.

The choice of model is a choice about operating effort and data location. A fully managed service has the least operating work. BYOC keeps data in your network and moves most of the operating work to the vendor. A self-managed cluster gives you every plane, and the work to run each one.

The Planes in AI Infrastructure

AI workloads add components to each plane, but the division stays the same.

• Data plane: model servers that generate tokens, embedding workers, vector indexes, retrieval, and the tools that agents call.
• Control plane: GPU scheduling, model version rollouts, autoscaling of inference replicas, and routing between model endpoints.
• Management plane: the model catalog, access to models and datasets, rate limits, cost reports, and evaluation results.

AI agents change the load on the data plane. One agent task can issue many queries, searches, and model calls in a few seconds. The data plane must enforce each agent's access scope locally. A policy check against a central service on every call adds latency and a new way to fail. The AI agent data access guide describes scoped access in more detail.

Advanced Topics

Reconciliation design

A reconciliation loop compares the complete desired state with the complete observed state on each pass. It does not depend only on individual change events. This level-based design recovers from missed events, restarts, and manual drift. Each action must be idempotent, so a repeated pass does not create duplicate resources.

Controllers also record their progress. A Kubernetes object carries a generation that increases with each change to its specification. Controllers report the generation they last applied, so a client can tell whether the running system reflects its latest change.

Configuration rollout and validation

One bad configuration can break every runtime at the same time. Control planes reduce that risk with validation and staged rollout. They check a configuration before they apply it, update a small group of runtimes first, and continue only after health checks pass. A blue-green rollout keeps the previous version in service until the new version is ready.

Push or pull delivery

A control plane can push configuration to runtimes, or runtimes can pull it on an interval. Push applies a change sooner. Pull needs no inbound connection, which is why BYOC designs often use it. Both designs need versioned configuration and an acknowledgment, so the control plane knows which version each runtime serves.

Telemetry across the plane boundary

Metrics, logs, and traces flow from the data plane to the planes above it. Query text and results can contain customer data. Decide which signals cross the boundary: counts and latencies usually can, but rows and prompts usually stay inside the data plane.

Not every coordinator is a control plane

A distributed query engine has a scheduler that plans each query and assigns tasks to executors. Every query passes through that scheduler, so it belongs to the data plane. Classify a component by whether a request waits on it, not by whether it directs other components.

Management, Control, and Data Planes with Spice

The Spice platform follows the same division. The Spice.ai runtime is the data plane in every deployment. The products around it supply the management and control planes, and they differ in who operates each plane.

The Spice.ai runtime is the data plane

The Spice.ai runtime (spiced) is one open-source process that serves the data plane. It runs SQL federation and acceleration across more than 40 data sources, hybrid SQL search, and LLM inference. Applications and agents call it over HTTP, Arrow Flight, or MCP.

A Spicepod (spicepod.yaml) declares the datasets, models, and settings that the runtime serves. When the runtime runs alone, that file in version control acts as the management plane. The runtime also does its own control work. It loads the Spicepod at startup, schedules each acceleration refresh, and reports readiness on /v1/ready.

Spice Cloud hosts the management and control planes

Spice Cloud runs all three planes as a managed service. Its management plane is a portal and a Management API, where teams manage organizations, members, projects, API keys, and secrets. Its control plane deploys each project's Spicepod, which comes from the portal editor or a connected GitHub repository.

Each new deployment runs the latest stable runtime version in the project's region. The managed runtimes form the data plane, and applications query them with a project API key. Spice Cloud pricing compares the managed and self-hosted editions.

Cloud Connect keeps the data plane on your hosts

Cloud Connect, in Private Preview, links a runtime that you operate to Spice Cloud. The runtime enrolls with spice cloud link, then opens an outbound gRPC stream secured with mutual TLS. Spice Cloud never opens a connection into your network.

Spice Cloud sends Spicepod deployments and encrypted secrets down that stream. The runtime sends heartbeats and metrics back, and source data and accelerated datasets stay on your host. If the connection drops, the runtime keeps serving with the last configuration it received. This is the static stability property from the figure above.

The Cloud Connect on a Development Machine recipe shows this split on one computer. It links a local Spice instance to Spice Cloud, deploys live changes to it, and sends it a secret.

Spice.ai Enterprise and the Kubernetes Operator

Spice.ai Enterprise is the self-hosted commercial distribution. It adds the Spice.ai Kubernetes Operator, multi-active clustering, acceleration snapshots, authorization policy, and 24/7 support. Teams install it from AWS Marketplace with a Helm chart.

The Kubernetes Operator is the control plane for Spice on Kubernetes. Teams declare a SpicepodSet, which holds a Spicepod and a replica count. A SpicepodCluster adds schedulers and executors for distributed query.

apiVersion: spice.ai/v2
kind: SpicepodSet
metadata:
  name: support-agent
spec:
  replicas: 3
  updateStrategy:
    type: BlueGreen
  spicepod:
    version: v2
    kind: Spicepod
    name: support-agent
    datasets:
      - from: s3://example-bucket/tickets/
        name: tickets
        params:
          file_format: parquet
        acceleration:
          enabled: true
          refresh_check_interval: 10m

The operator reconciles each resource into StatefulSets, a Service, and a ConfigMap that holds the Spicepod. It rolls out a change one pod at a time by default. A BlueGreen rollout starts a complete new set of pods and switches the Service to them after they report ready.

The runtime pods are ordinary Kubernetes workloads. If the operator stops, Kubernetes keeps the pods running, and they continue to serve queries. Rollouts wait until the operator returns. The edge-to-cloud deployment guide compares this cluster model with sidecar and microservice deployments.