Three planes, one principle: customer keeps the data.
Eisberg is built so that on the day you decide we are not the right partner, your data is already in Apache Iceberg in your bucket — and any other engine on earth can read it. That is the whole point. Every architectural choice that follows is in service of that one promise.
Control plane
Eisberg-managed
- API · Auth · Billing
- Agent scheduler & MCP gateway
- Tenant config · Policy plane
- Intelligence OS · Lineage graph
Compute plane
Neo-cloud GPUs
- GPU-accelerated query workers
- Distributed federated query workers
- Sensor-scale stream processing
- Per-query routing · Auto-fallback
Data plane
Customer-owned
- Apache Iceberg · Open format
- S3 / Azure Blob / GCS
- Customer-managed KMS keys
- Eisberg never stores customer data
What runs where, and why it matters.
The plane separation is not a marketing claim — it is enforced by the credentials each plane has. The control plane never has the KMS keys for customer data. The compute plane runs in the customer's cloud account when configured. The data plane is unconditionally on customer storage.
Control plane
Authorization, governance, agent identity, policy compilation, audit logging.
Runs on Eisberg infrastructure. Holds policy bundles, agent Birth Certificates, audit-trail metadata. Never holds customer data records.
Compute plane
Query execution, ingestion, transformation, agent actions, ML inference.
Runs on customer or shared infrastructure depending on deployment mode. BYOC option runs entirely in the customer's cloud account. Same Helm manifest either way.
Data plane
Storage of every customer table, every Iceberg manifest, every snapshot.
Always on customer-owned object storage. Encrypted with customer KMS keys. Eisberg never has the credentials or the ability to read it directly.
Built for the next hardware shift, not the last one.
Storage, caching, query routing, and compute scheduling are written behind interfaces. The next generation of memory and compute hardware — CXL memory pooling, shared-memory accelerators, persistent memory tiers — slots in as a new backend without touching application code. Incumbents rewrite themselves to make the same move.
The substitution surface
Memory tier abstraction, pluggable storage backends, swappable query engines, swappable AI model router, swappable catalog implementation. The next decade's hardware shift becomes a configuration change, not a re-architecture project.
The CXL bet
Production CXL memory pooling is starting to ship in 2026 for AI training workloads. Data-platform deployment is 2027-2029 territory. Eisberg's memory tier abstraction lets that arrive as a new backend with bounded migration cost. Forward architecture for buyers thinking past the next budget cycle.
Detailed forward-architecture rationale, threat model, and Agent Birth Certificate specification are available under NDA. We share them with design partners and serious prospects on the second call.
Want the full architecture deck?
The deep-dive — including component choices, threat model, agent governance specification, and the forward-architecture rationale — is available under NDA. We send it in advance of every architect-level evaluation so your team has the receipts before the call.