> For the complete documentation index, see [llms.txt](https://docs.e6data.com/query-engine/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.e6data.com/query-engine/get-started/architecture/detailed-architecture-walkthrough/key-characteristics.md).

# Key Characteristics

### What defines the architecture

**KUBERNETES-NATIVE** — *Every service runs on Kubernetes*\
Every service in the engine runs as pods managed by e6data's Kubernetes operators — provisioning, scaling, upgrades, and monitoring are all K8s-native operations. Because the platform speaks Kubernetes rather than any one cloud's control plane, the same engine runs identically on AWS, GCP, and Azure, as well as on-premises and in sovereign clouds.

**PLANNER-EXECUTOR MODEL** — *Planner and executor scale atomically*\
Many engines pair a driver with workers; under high concurrency the driver becomes a bottleneck. e6data separates planning from execution as independent services, and capacity moves in the smallest useful unit — a single planner or executor — driven by live load and query complexity rather than step-jump scaling of entire warehouses. High concurrency grows the planning tier; heavy scans and joins grow the executor fleet. It shrinks the same way.

**MULTI-DIALECT** — *Run queries written for any engine*\
A transpiler service converts SQL from other dialects into the E6 dialect before planning, and the protocol layer speaks the Postgres wire, Trino, and Spark protocols. Queries, BI tools, and jobs written for other engines move over without a rewrite.

**LAKEHOUSE-NATIVE** — *Your data never crosses your boundary*\
Queries run directly against Apache Iceberg, Delta Lake, Hudi, and Parquet in your object store, through the catalogs you already run. Nothing is ingested and nothing is copied into vendor storage.

**RUST · ARROW CORE** — *Vectorized, columnar from storage to result*\
The executor is Rust-based and Arrow-centric: operators process data as column vectors in batches, performance-critical kernels run natively with zero JVM overhead, and data stays in Arrow's columnar form all the way from scan to result.

**SMART PLAN OPTIMIZATIONS** — *Automatic plan-level optimizations*\
The optimizer reduces work at planning time: common CTEs are detected and computed once, joins that don't affect the result are eliminated, and large join graphs are handled with hypergraph enumeration and A\* search. A learning feedback loop refines plans using runtime cardinalities as the workload changes.

**DISTRIBUTED EXECUTION** — *Work is distributed before it is spilled*\
Plans are divided into fragments that run in parallel across the executor fleet, with joins and aggregations redistributing data so no single worker holds the whole working set. Hierarchical memory tracking and spill-to-disk handle workloads that exceed memory.

**WORKLOAD ISOLATION** — *Concurrent workloads share the cluster predictably*\
Scheduling algorithms place work across executors to maximize throughput, while queueing and admission control keep interactive dashboards, scheduled jobs, and ad-hoc analysis running side by side. Configurable guardrails prevent one bad query from disproportionately impacting other queries. Per-query execution metrics — operator timings, rows read, cache hits, spill volume — are recorded in query history.

**CACHING** — *Multi-tiered caching*\
Metadata is cached without sacrificing immediate consistency — the engine always plans against the current state of your tables. Data is cached across memory and NVMe disk. Result sets are cached, so repeated queries are answered without re-execution.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.e6data.com/query-engine/get-started/architecture/detailed-architecture-walkthrough/key-characteristics.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.