| Architectural dimension | e6data | Typical cloud data warehouse | Typical lakehouse platform |
|---|---|---|---|
| Where your data lives | In your lake, in place — queried directly, never ingested | Ingested into vendor-managed storage | In your lake, alongside platform-managed workspaces |
| Storage format | Open only: Iceberg, Delta Lake, Hudi, Parquet | Proprietary internal format; open formats layered on | One favored open format; others via interop layers |
| Dialects & protocols | Transpiles other engines’ dialects to E6 SQL; speaks Postgres wire, Trino, Spark, gRPC | Own SQL dialect; vendor drivers required | Own dialect; clients use platform drivers |
| Compute model | Independently scalable planner and executor tiers — no driver bottleneck | Fixed-size virtual warehouses | Driver-and-worker clusters and serverless pools |
| Scaling granularity | Atomic — add one planner or one executor at a time, on load and query complexity | Step jumps — whole-warehouse resize or multiply | Node-level within a cluster |
| Execution engine | Vectorized columnar engine, Rust-based and Arrow-centric | Proprietary vectorized engine | Vectorized engine over a JVM-based runtime |
| Catalog & governance | Attaches to your existing catalogs and governance — Hive Metastore, Glue, Unity, Polaris/IRC, Ranger | Vendor’s own catalog at the center | Platform’s own catalog at the center |
How the architecture compares
e6data combines the compute–storage separation of cloud warehouses with the open formats of lakehouse platforms, and adds a compute plane that is stateless, granular, and protocol-compatible with existing tools.
Category columns describe common architecture patterns, not any specific product, and are intended as an architectural orientation rather than a feature matrix.
Last modified on September 29, 2026