Problem 01
Snapshot consistency.
Spark commits at 14:00. Trino still reads the stale snapshot at 14:02 because nobody told it. We pin a snapshot ID across every reader for a query window.
Open Lakehouse Control Plane · v0.4 beta
The coordination layer for multi-engine Iceberg lakehouses.
Snapshot consistency, schema invalidation, cross-engine row-level security — for lakehouses where Spark writes, Trino reads, and Dremio queries the same table from three different sides.
v0.4 · design partner phaseself-hosted or managedSOC 2 Type II in progress
The multi-engine reality
Seven runtime problems no catalog solves.
Iceberg gives you tables. Polaris gives you a REST catalog. Neither solves the coordination problems that show up between engines at 14:00 every Wednesday. We do.
Problem 02
Schema invalidation.
You add a column. Three engines have three different schema caches. Until each one TTLs out you get nulls, errors, or worse — wrong types. We invalidate caches in <5s.
Problem 03
Write conflicts.
Two engines committing into the same table is undefined behavior. We coordinate a single writer per partition window with explicit handoff.
Problem 04
Compaction coordination.
Compaction rewrites files. Readers mid-query hit the wrong files. We pin reader snapshots through the compaction window.
Problem 05
Metric drift across engines.
Same metric, different engines, different definitions. We carry the metric definition with the table, not the BI tool.
Problem 06
AI agents reading without guardrails.
An LLM agent that can query your warehouse can also bypass your row filters. We enforce policy at evaluation time, not at the BI tool layer.
Problem 07 · the one that matters
Cross-engine row-level security.
Unity Catalog's row filters and column masks are not enforced through the Iceberg REST API. Your governance posture changes the moment another engine reads the same table. We close that gap.
Neksur
One runtime, all seven solved.
Spark, Trino, Snowflake, Dremio — same Iceberg table, same coordination layer, same policy contract.
What Neksur does
Three jobs. One runtime.
01 · Coordinate
Snapshots, schemas, partitions — synced.
Engines share state through the same control plane. No vendor-specific glue.
- cross-engine snapshot pinning
- schema-cache invalidation, p99 < 5s
- partition-spec evolution propagation
02 · Govern
Policy at the catalog. Enforced everywhere.
One declarative policy contract compiled and enforced identically on every engine at runtime.
- SQL-native predicate language
- OIDC identity propagation
- per-evaluation audit log
03 · Expose
Semantics that survive the engine boundary.
Bit-identical metric and dimension semantics across every query engine, carried with the table.
- metric registry with lineage
- BI-tool integration (read-only)
- query-plan annotations
Architecture
A thin metadata layer. Not on the query path.
Neksur sits between your engines and the REST catalog. It coordinates state via the standard Iceberg REST APIs — your engines do not need patches, agents, or wrapper drivers.
Coordination happens in metadata, not on the data path. Your engines do not need patches, agents, or wrapper drivers — only the standard Iceberg REST catalog endpoint.
How we read against the field
Different category. Adjacent products.
Polaris solves metadata. Cube solves semantics. Atlan solves discovery. Snowflake solves Snowflake. Neksur solves what happens between engines at query time.
| Vendor | Semantic Consistency | Runtime Coordination | Policy Enforcement |
|---|---|---|---|
| Neksur | ●metric registry + roundtrip-stable OSI | ●snapshot pin, schema cache, write coord | ●default-deny, runtime-enforced, all engines |
| Unity Catalog | —no native metric layer | ○Spark-coupled, no cross-engine pin | ○row filters not enforced via Iceberg REST (Apr 2026) |
| Polaris | —metadata only, no semantics | —REST catalog only, no runtime layer | —auth-only, no row/column policy |
| Horizon | —not in scope | ○Snowflake-only coordination | —no cross-engine policy |
Who Neksur is for
Three roles. One control plane.
Persona 01
The data platform engineer.
Pain
You spend Wednesdays untangling Trino-Dremio disagreement.
Neksur
One snapshot, every engine.
Persona 02
The security architect.
Pain
Your auditor wants per-engine RLS proof you cannot produce.
Neksur
Policy defined once, evaluated per-engine, logged and signed.
Persona 03
The CDO.
Pain
Four engines, three catalogs, two semantic layers — and nobody owns the contradictions.
Neksur
A thin layer that makes open architectures behave like one platform.
Design-partner phase · 4 of 8 slots filled
Ready to coordinate?
We work with one new design partner per month through Q3 2026. If you're running open Iceberg at scale with three or more engines and at least one of the seven problems above is costing you on-call time, we should talk.