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.

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

Category columns describe common architecture patterns, not any specific product, and are intended as an architectural orientation rather than a feature matrix.