Why Composability Requires Three Layers, Not Just Model Routing

Composable data infrastructure is architecture in which infrastructure, data, and AI each behave as governed, interchangeable modules: the platform deploys identically on any Kubernetes cluster with least-privilege access, every data source is reachable through one governed interface, and any model or agent runs under the same identity and policy envelope, on infrastructure you control.

"Composable" now appears in the marketing of nearly every data and AI vendor, and it rarely means the same thing twice. The most common usage in 2026 is also the narrowest: a platform calls itself composable because it can route requests across many models, or swap one query engine for another behind an API. The buyer's guides for that category alone compare dozens of routers and gateways, and one managed gateway advertises routing across more than 400 models through a single interface [27][28][29]. Routing is real engineering, and we ship an intelligent router ourselves, but interchangeability at one seam of the stack tells you nothing about the other seams. A platform can swap models freely and still hold your tables in a format only it reads, run only in its own cloud, and enforce identity only inside its own walls.

This guide gives you a definition you can test. True composability spans three layers: the infrastructure the platform runs on, the data it governs, and the AI that runs against that data. We define each layer, show why the routing-only definition fails buyers, and close with the four-question litmus test we encourage you to put to any vendor, including us. Our earlier essays on composable architecture, along with our guide to AI query routing as infrastructure, are collected in the NexusOne resource library.

What Does Composable Data Infrastructure Mean for Enterprise AI Teams?

The word has a longer and more precise history than current vendor copy suggests, and every tradition that used it seriously meant the same two things: modular parts, and standard interfaces those parts agree on in advance.

Gartner's composable enterprise, the framing that made the word popular with executives, describes organizations assembled from packaged business capabilities, software components that each represent one well-defined business capability and communicate with everything else through APIs, governed by four principles: modularity, autonomy, orchestration, and discovery [1][2]. The MACH architecture movement, organized by an alliance of commerce and content vendors in 2020, applied the same idea to application stacks: microservices, API-first, cloud-native, headless, so that any service can be replaced without rebuilding the whole [3][4]. The data center hardware world uses composable disaggregated infrastructure to mean compute, storage, and network pooled by software and assembled per workload through API calls, then returned to the pool when the workload ends [8][9]. And database engineering produced the most rigorous version: the Composable Data Management System Manifesto, published at VLDB 2023 by engineers from Meta, Voltron Data, Databricks, and Sundeck, argues for decomposing monolithic engines into reusable components that share open standards such as Apache Arrow for in-memory data and Substrait for query plans [5][6][7].

Every row makes the same promise: a module can change without the rest of the system noticing. For an enterprise AI team, that promise carries an extra clause the older traditions never had to state, because their modules did not roam. AI agents do. An agent answering one question may touch a warehouse, an on-prem database, and an object store in a single pass, so for AI work the module boundary that matters is governance: a platform is composable for AI when an engine, a model, a cloud, or a data source can change without breaking identity, policy, or context anywhere in the estate.

Where the Model Routing Definition of Composability Falls Short

Judged against any of those four traditions, model routing covers one module boundary out of the dozens an enterprise estate contains. The routing market is crowded, with 2026 comparisons ranking gateways on provider coverage, latency overhead, caching, and failover across dozens of products [27][28][29], and that crowding is exactly why vendors reach for a bigger word. Swapping GPT for Claude behind one API is interchangeability at the model seam, and nothing more.

Three changes expose the difference. First, move the platform itself: from the vendor's cloud to your data center, or into an air-gapped environment. A composable platform redeploys with configuration changes, while most routing products cannot leave the environment they were built for, which makes the router itself a fixed, non-swappable module. Second, add a data source the platform does not own, such as a mainframe extract or a second cloud's object storage, and watch whether governance extends to it or stops at the platform edge. Third, follow one agent across systems and ask whether it carries the same identity and policy in each one, because an agent that changes identity at every boundary is not operating in a composed system, it is hopping between silos.

When a prospect tells us they have heard "composable" before, we agree, and we offer a sharper version: most platforms mean "we have an API." An API is a prerequisite. Composability is when one policy, defined once, governs every engine and storage system simultaneously, and when swapping a compute engine leaves the governance layer untouched because every piece communicates through one shared model. That standard has to hold at three separate layers, so the next three sections take them in order.

Layer One: Composable Infrastructure Plugs Into Your Kubernetes With Least Privilege

Infrastructure composability is decided on the day your platform team reads the deployment manifest, because the manifest reveals how much of your cluster the vendor expects to own. Three definitions frame the stakes. A Kubernetes namespace is a partition of a cluster that scopes names, resources, and permissions to one tenant. Least privilege is the security principle of granting a workload only the permissions it needs to function, a control the NSA and CISA place at the center of their Kubernetes hardening guidance [14][15]. A Kubernetes operator is software installed on a cluster to automate an application, usually holding standing permissions to create and modify cluster resources on its own.

Operators are where infrastructure composability most often fails in practice. Red Hat's own guidance on operator security recommends namespace-scoped operators over cluster-scoped ones wherever possible, precisely because operators tend to accumulate permissions [10]. Snyk's analysis reaches the blunter conclusion that an operator running with cluster-admin rights is a single point of failure if compromised [11], OWASP ranks overly permissive RBAC among its top ten Kubernetes risks [12], and recent academic work has cataloged how cross-namespace references in operators break the isolation namespaces are supposed to provide [13]. A vendor stack that arrives with a family of privileged operators is asking your security team to underwrite all of that surface.

NexusOne took the opposite bet. The entire platform, roughly 100 containers spanning more than 85 integrated open-source tools, deploys into a single Kubernetes namespace with least-privilege permissions, no cluster-wide operators, and nothing running with cluster-admin rights, inside a cluster you already own and continue to control. In competitive deployments we have reviewed, two other postures recur. One installs a set of vendor-specific operators, often around ten, holding broad cluster permissions; IBM's watsonx.data, for example, installs through the Operator Lifecycle Manager as operators alongside the Cloud Pak for Data control plane [16][17]. The other declines your cluster altogether: Cloudera's on-premises data services run either on OpenShift or on Cloudera's Embedded Container Service, which creates and manages its own embedded Kubernetes on hosts you supply [18][19]. Neither posture is wrong for every buyer, but in both cases the platform sets the terms of the environment rather than adapting to yours, and your security team inherits the difference. In our deployments, the narrow, standard footprint is what lets a bank's platform security review clear in days; the pattern we have observed when a stack demands cluster-wide operators or its own Kubernetes distribution is clearance measured in months.

The second half of infrastructure composability is the perimeter, because certificates, DNS, storage, and identity differ at every enterprise, and they are where deployments stall. Certificate automation alone is a discipline: Kubernetes components and workloads authenticate with short-lived TLS certificates that must be issued and rotated continuously, which is why cert-manager became the de facto in-cluster automation tool and graduated in the CNCF in November 2024, and why enterprises still route it through external PKI platforms such as Venafi to keep governance intact [20][21][22][23]. NexusOne normalizes this perimeter through pluggable environment adapters: modules for Venafi, Akamai, the cloud providers' certificate authorities, Let's Encrypt, and other systems, driven by a few configuration values rather than per-service manual work. A provider we have not yet built a module for takes real engineering before it plugs in cleanly, but each module is small and the catalog grows with every deployment.

Portability then has to survive scale, and this is where the composable-infrastructure claim gets its hardest test. Our smallest customer runs the platform on roughly 100 cores and our largest on roughly 400,000, and both run the same exact image, one artifact across a four-thousand-fold range. That property matters more every year, because the average Kubernetes adopter now runs clusters in more than five environments, 37 percent of organizations manage over 100 clusters, and 88 percent report rising Kubernetes total cost of ownership year over year [24][25][26]. A platform that behaves differently per environment multiplies that burden by every cluster you add.

Layer Two: Composable Data Puts One Governed Interface Over Every Source

A data layer is composable when both halves of it stay open: the format your tables live in, and the path every engine and agent takes to reach them.

The format half has largely been settled by the market. An open table format is a specification, most prominently Apache Iceberg, that lets any engine read and write the same tables in object storage with transactional guarantees, so your data stops being an artifact of one vendor's engine. The competitive stampede told you how much this matters: Snowflake open-sourced its Polaris catalog for Iceberg, Databricks acquired Tabular, the company founded by Iceberg's creators with roughly 40 employees, for a reported price above $1 billion, and the major clouds followed with Iceberg catalog support of their own [30][31][32][33]. When the two largest Gen 2 platforms spend that heavily to be seen as open at the storage layer, the format war is over and Iceberg won.

Formats are the floor, though, and an estate can hold every byte in Iceberg and still fail the composability test, because each engine that reads those tables can bring its own permissions model, its own catalog, and its own audit log. The access half of composable data is one governed interface across every source. Federated query, the technique of querying data where it lives across many systems instead of copying it into one, supplies the reach, and governance has to travel with it. In NexusOne, a policy defined once in Apache Ranger enforces simultaneously across Trino, Spark, NexusOne's Kubernetes-optimized serving layer built on Apache Kyuubi, and S3 object storage on a per-object basis, and tagging a dataset in DataHub generates those policies automatically across every engine and storage system that can touch the data. The compute comes to the data rather than the data being dragged to the compute.

A data layer that claims composability should check every box on this list:

• One interface reaches operational, analytical, and unstructured data, on-prem and in every cloud you run

• One policy model enforces identically across every query engine and every storage system, with no per-engine policy redefinition

• Identity flows from one source, so a user or agent exists once rather than once per system

• Business context, lineage, and quality rules travel with the data to whichever engine or agent touches it

• Adding an engine or a source is a configuration event, without a governance project attached

• You can read and write through the interface, because an estate you can only read from is a reporting layer

Any platform can pass the first item inside its own walls. The test is whether the list holds across systems the platform does not own, which is where a walled implementation drifts back into the thing composability was supposed to replace.

Layer Three: Composable AI Runs Any Model Under One Identity, on Your Estate

The AI layer is composable when the model is the swappable module and everything around it stays fixed: identity, policy, audit, and context do not change when the model does.

Identity is the anchor. In NexusOne, an AI agent inherits the permissions of the user who invoked it, enforced by the same identity model that governs human access across every engine, catalog, and storage system, and an agent can also carry its own scoped identity when you need to constrain it independently. Policy is evaluated before a request reaches a model or the data, and every decision lands in one audit trail. That is what allows a model swap to be boring, in the best sense, because the governance envelope never moved.

Composable AI also decides where models run. A small language model (SLM) is a compact model, typically under 10 billion parameters, that handles narrow tasks on modest hardware you own. When the first two layers exist, a router can send a deterministic question to a query engine, a narrow task to an SLM sitting beside the data, and only open-ended generative work to a frontier endpoint, because the governed paths to all three destinations already exist. This is routing in its proper place: the visible feature on top of two layers of architecture, rather than a substitute for them. The NexusOne AI & Data Control Plane packages this as one governed boundary over every model, engine, user, and agent in the estate, with early deployments underway that include a top-ten US bank; the AI & Data Control Plane product page covers it in depth.

Sovereignty is the reason "on your estate" belongs in the definition. A composable AI layer can place a workload on your own hardware as easily as on a cloud endpoint, and enterprises are exercising that option: a Barclays CIO survey found 83 percent of enterprises planning to move some workloads back to private infrastructure, IDC found roughly 80 percent expecting to repatriate some compute or storage within twelve months, and sovereignty ranks alongside cost and performance among the stated drivers [34][35]. We believe more compute returns on-prem this decade than moves to cloud, and the early market data points the same direction, but the architectural point stands on its own regardless of pace: if your AI layer only runs where your vendor runs, it is not composable, whatever the routing table says.

Normalization Collapses Thousands of Integrations Into One Surface

The mechanism underneath all three layers is normalization: reduce infrastructure, data, and AI to one known standard, and integrate everything against that standard once. The arithmetic explains why this is the whole game. Wire 85 tools to each other point-to-point and you face up to 3,570 pairwise integrations, each with its own identity handoff and failure modes; normalize all 85 to one shared surface for identity, policy, and context, and you maintain 85 integrations, one per tool. The composable data systems community reached the same conclusion from the engine side, arguing that shared open standards are what turn a pile of components into a stack [5][7].

Normalization is also why "composable SaaS" claims deserve skepticism. A SaaS platform controls its own environment top to bottom: its own Kubernetes, its own certificates, its own identity provider, its own storage. Inside that walled environment, everything composes, because the vendor pre-integrated it against pieces the vendor chose. The hard problem, the one composability was named for, is running inside someone else's environment, where you control none of the pieces and must normalize whatever certificates, DNS, storage, and identity providers you find. A vendor that has never had to solve that problem has never had its composability tested, and buyers can apply that test in one question: show me this platform running in a customer's cluster, against a customer's PKI, at a customer's scale.

Why Not Just Standardize on a Single Platform Instead?

The strongest objection to the three-layer standard deserves a straight answer: a single vertically integrated platform is simpler to buy, simpler to staff for, and pre-composed by the vendor, so why take on composability at all?

For some estates, you should not. If your data lives in one cloud, your workloads fit one platform, and you face no sovereignty, residency, or on-prem constraint, a Gen 2 platform is the pragmatic choice, and paying for composability you will never exercise is waste. We tell prospects in that position to stay put, because the cross-estate advantage only pays when a cross-estate problem exists.

Most large enterprises have the problem. The average adopter already runs Kubernetes across more than five environments [25], estates span mainframes, multiple clouds, and on-prem systems accumulated over decades, and agentic workloads cross those boundaries by design. The other escape route, building composability yourself from the same open-source tools we use, is real but expensive: the tools download for free, while the cross-system wiring that makes one identity flow through every engine and one policy enforce everywhere ran past ten thousand engineering hours in our own build, and you would be spending those hours during the window when your competitors are deploying AI. The honest framing is a two-by-two: single-environment estates are well served by vertical platforms, and cross-boundary estates need the three layers, bought or built.

What Enterprise-Grade Composable Data Infrastructure Looks Like in Production

The three layers sound abstract until you watch a deployment, so here is the sequence as it has run at our customers. Your security team reviews one namespace footprint, a set of least-privilege permissions, and roughly 100 containers, rather than a new distribution or a family of privileged operators, and in recent engagements that review has cleared in days. The environment adapters take your certificate authority, DNS, storage, and identity providers as configuration values. From an empty namespace, the platform stands up as a governed estate in under an hour in recent deployments, and every tenant provisioned afterward inherits the full layer: identity, policy, catalog, and connected sources. Embedded Builders, NexusOne engineers who build alongside your team rather than advising from a deck, then wire your specific systems into the layer, from cloud warehouses down to mainframe extracts. The artifact they deploy is the same image our smallest and largest customers run, from 100 cores to 400,000.

From that point, each layer's composability is something you exercise rather than trust. Swap in a new query engine and the Ranger policies already govern it. Point the estate at a new cloud and the adapters normalize it. Adopt next year's model and it inherits this year's identity, policy, and audit trail. To see the sequence against your own environment, schedule an expert consultation and bring your hardest integration.

Put the Four-Question Litmus Test to Every Vendor, Including Us

Composability claims resolve quickly under four questions. We use this test in our own sales conversations, and we encourage you to run it on every platform in your evaluation.

1. Is your infrastructure composable? Does one version of the platform run identically on any cloud, on-prem, hybrid, or air-gapped, plugging into the customer's own Kubernetes with least privilege, or does it require its own cluster, privileged operators, or a specific cloud?

2. Is your identity and security composable? Does one identity model, federated from the customer's existing providers, govern every system with scoped roles, a single point to grant or revoke access, and one audit trail?

3. Is your data composable? Does one governed interface reach operational, analytical, and unstructured data wherever it lives, under one policy model, with context that travels?

4. Is your AI composable? Can any model or agent run under that same identity and policy, deployable on the customer's own estate for sovereignty?

Closed platforms answer all four the same way: only inside our ecosystem. That answer is not evasion, it is architecture, because a vertical platform structurally cannot extend its identity, governance, or deployment model beyond its own walls. Model routing, the feature most often offered as proof of composability, answers a question the test does not ask.

The estates being built now will absorb the next model generation, the next regulation, and the next deployment mandate, and the ones that absorb them without replatforming will be the ones composed of layers that were designed to be swapped. If you want to pressure-test the four questions against your architecture, talk to our team and put us through the test first.

Frequently Asked Questions

What's the Best Enterprise-Grade Composable Data Infrastructure in the Data Platform Space?

The strongest candidates are the platforms that pass a composability test at all three layers rather than one. NexusOne is built specifically for that standard: it deploys into a customer's own Kubernetes as roughly 100 containers in a single least-privilege namespace, places one governed interface over data in every connected system through open formats like Apache Iceberg, and runs any model or agent under one identity and policy envelope, on infrastructure the customer controls. Vertically integrated platforms such as Databricks and Snowflake deliver strong pre-composed experiences inside their own environments, and the right choice depends on whether your estate crosses boundaries those environments cannot reach.

Which Data Platform Company Has the Best Composable Data Infrastructure for Analytics Teams?

For analytics teams working across multiple engines and sources, the differentiating capability is governance that survives an engine swap. NexusOne enforces one Apache Ranger policy simultaneously across Trino, Spark, its Kyuubi-based serving layer, and S3 object storage, so analysts change engines without a governance project, and tagging a dataset in the catalog generates policies across all of them automatically. Companies whose composability consists of an API or a model router leave each engine's permissions and catalogs separate, which is the gap analytics teams feel first as their estate grows.

Best Cloud-Native Data Platform for Composable Data Infrastructure

Cloud-native, in the composable sense, means Kubernetes-native and cloud-neutral rather than built for one vendor's cloud. NexusOne is a fully containerized, stateless platform that runs the same image on any conformant Kubernetes, from a hyperscaler's managed service to an on-prem or air-gapped cluster, spanning deployments from roughly 100 cores to roughly 400,000 on one artifact. That portability, combined with open table formats and a single cross-estate governance model, is what separates a cloud-native composable layer from a cloud-hosted platform that composes only within its own service perimeter.

What Does Composable Data Infrastructure Mean for Enterprise AI Teams?

For an AI team, composable data infrastructure means any module in the stack, an engine, a model, a cloud, or a data source, can change without breaking identity, policy, or context anywhere in the estate. That property is what makes agentic workloads governable, because agents cross system boundaries by design and need to carry one identity and one policy envelope everywhere they go. In practice, it also determines cost and sovereignty options: a composable AI layer can route work to a query engine or a small language model beside the data, and can run sensitive workloads on infrastructure the enterprise owns instead of a vendor's endpoint.

References

1. Trisotech, "Composability and Packaged Business Capabilities." https://www.trisotech.com/composability-and-packaged-business-capabilities/

2. WalkMe, "What Is Composable Enterprise?" https://www.walkme.com/glossary/composable-enterprise/

3. MACH Alliance, "MACH at Different Levels." https://machalliance.org/insights-hub/mach-at-different-levels

4. Sitecore, "What Is MACH Architecture?" https://www.sitecore.com/resources/insights/development/what-is-mach-architecture

5. Pedreira, P. et al., "The Composable Data Management System Manifesto," Proceedings of the VLDB Endowment, Vol. 16 (2023). https://www.vldb.org/pvldb/vol16/p2679-pedreira.pdf

6. Wes McKinney, "The Future Roadmap for the Composable Data Stack," Data Council 2024 talk transcript. https://wesmckinney.com/transcripts/2024-03-26-data-council-composable-data-stack

7. Voltron Data, "Open Standards Over Silos," The Composable Codex. https://voltrondata.com/codex/open-standards

8. TechTarget, "Everything You Need to Know About Composable Infrastructure." https://www.techtarget.com/searchdatacenter/feature/Everything-you-need-to-know-about-composable-infrastructure

9. Network World, "What Is Composable Infrastructure?" https://www.networkworld.com/article/965432/what-is-composable-infrastructure.html

10. Red Hat, "Kubernetes Operators: Good Security Practices." https://www.redhat.com/en/blog/kubernetes-operators-good-security-practices

11. Snyk, "Security Implications of Kubernetes Operators." https://snyk.io/blog/security-implications-of-kubernetes-operators/

12. OWASP Foundation, "K03: Overly Permissive RBAC," OWASP Kubernetes Top Ten. https://owasp.org/www-project-kubernetes-top-ten/2022/en/src/K03-overly-permissive-rbac

13. "Breaking the Bulkhead: Cross-Namespace Reference Vulnerabilities in Kubernetes Operators," arXiv:2507.03387. https://arxiv.org/html/2507.03387

14. NSA and CISA, "Kubernetes Hardening Guidance," Version 1.2, August 2022. https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF

15. Kubernetes Blog, "A Closer Look at NSA/CISA Kubernetes Hardening Guidance." https://v1-32.docs.kubernetes.io/blog/2021/10/05/nsa-cisa-kubernetes-hardening-guidance/

16. IBM Documentation, "Installing watsonx.data," IBM Software Hub 5.1.x. https://www.ibm.com/docs/en/software-hub/5.1.x?topic=watsonxdata-installing

17. IBM Documentation, "Installing IBM Cloud Pak for Data." https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0.0?topic=installing

18. Cloudera Documentation, "The Embedded Container Service (ECS)." https://docs.cloudera.com/cdp-private-cloud-data-services/1.4.0/managing-ecs/index.html

19. Cloudera Documentation, "Installing Cloudera Data Services on Premises Using Cloudera Embedded Container Service." https://docs.cloudera.com/cdp-private-cloud-data-services/1.5.4/installation-ecs/topics/cdppvc-installation-ecs-steps.html

20. cert-manager, "Venafi and cert-manager." https://venafi.cert-manager.io/

21. OneUptime, "How to Implement cert-manager Integration with External PKI Infrastructure." https://oneuptime.com/blog/post/2026-02-09-cert-manager-external-pki/view

22. Red Hat Developer, "Automate Certificate Management in OpenShift." https://developers.redhat.com/articles/2025/09/24/automate-certificate-management-openshift

23. GlobalSign, "Simplify PKI in Kubernetes Environments and Accelerate DevOps." https://www.globalsign.com/en/blog/simplify-pki-kubernetes-environments-and-accelerate-devops

24. Efficiently Connected, "Kubernetes Complexity and AI Reshape Enterprise Operations" (on the Komodor 2025 Enterprise Kubernetes Survey). https://www.efficientlyconnected.com/kubernetes-complexity-and-ai-demands-redefine-enterprise-operations/

25. Spectro Cloud, "State of Production Kubernetes 2025." https://www.spectrocloud.com/state-of-kubernetes-2025

26. Business Wire, "Spectro Cloud's 2025 State of Production Kubernetes Report Finds AI Driving Growth as Cost Pressures Bite," August 2025. https://www.businesswire.com/news/home/20250804240622/en/

27. Braintrust, "Best LLM Routers and Model Routing Platforms in 2026." https://www.braintrust.dev/articles/best-llm-routers-2026

28. Not Diamond, "The Top 10 AI Gateways for the Multi-Model Future (2026)." https://www.notdiamond.ai/blog/the-top-10-ai-gateways-for-the-multi-model-future-2026

29. Requesty, "Best LLM Routing Platforms Compared (2026): Requesty, Portkey, LiteLLM, OpenRouter, and More." https://www.requesty.ai/blog/best-llm-routing-platforms-compared-2026-requesty-portkey-litellm-openrouter

30. Databricks, "Databricks Agrees to Acquire Tabular, the Company Founded by the Original Creators of Apache Iceberg," June 2024. https://www.databricks.com/company/newsroom/press-releases/databricks-agrees-acquire-tabular-company-founded-original-creators

31. SiliconANGLE, "Databricks Acquires Tabular in a Big Move to Close the Compatibility Gap with Apache Iceberg," June 2024. https://siliconangle.com/2024/06/04/databricks-acquires-tabular-big-move-close-compatibility-gap-apache-iceberg/

32. The New Stack, "Snowflake, Databricks and the Fight for Apache Iceberg Tables." https://thenewstack.io/snowflake-databricks-and-the-fight-for-apache-iceberg-tables/

33. Starburst, "Snowflake, Databricks, Tabular, Iceberg: What Does It All Mean?" https://www.starburst.io/blog/snowflake-databricks-tabular-iceberg/

34. Puppet, "The Great Repatriation: Why Enterprises Are Moving Workloads Back On-Premises." https://www.puppet.com/blog/cloud-repatriation-trends-2026

35. NovoServe, "Cloud Repatriation: Trends and Statistics of Enterprises Leaving Cloud." https://novoserve.com/blog/cloud-repatriation-trends-and-statistics-of-enterprises-leaving-cloud