> ## Documentation Index
> Fetch the complete documentation index at: https://docs.e6data.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How the engine plans and runs a query

> The stages a query goes through in e6data, from connect and submit to streamed results.

**ARCHITECTURE · QUERY LIFECYCLE**

From SQL text to streamed results, every stage is handled by a dedicated component — and every stage is observable.

***

### 01 Connect & submit

#### Protocol Layer

*Connect & submit*

A client submits SQL over the PostgreSQL wire protocol, the Trino protocol, the Spark protocol, or gRPC. The protocol layer authenticates the session and routes the statement to the planner for its workspace — no client rewrite required.

### 02 Transpile, parse & validate

#### Transpiler · Query Planner

*Transpile, parse & validate*

SQL written in another engine's dialect is first transpiled to the E6 dialect. The planner then parses the query, resolves tables and columns against the metadata services, and validates types — surfacing errors in milliseconds, before any compute is spent.

### 03 Optimize

#### Query Planner · Cost-based optimizer

*Optimize*

Rewrite rules, cost-based optimization, and a learning optimizer informed by past executions reorder joins, push down filters and projections, and exploit table-format metadata to prune partitions and files. The output is a physical plan sliced into distributable fragments.

### 04 Schedule

#### Distribution Services

*Schedule*

Admission control places the query, allocates executors, and enforces workload isolation — so a heavy ad-hoc query and a latency-sensitive dashboard can share the same cluster predictably.

### 05 Execute

#### Distributed Executors · Native Engine

*Execute*

Plan fragments run in parallel across the executor fleet as pipelines of vectorized columnar operators, exchanging data between executors for large joins and aggregations. Kernels run in native Rust on Apache Arrow; scans hit the multi-tier cache first, then read open table formats from your lake in place, with spill-to-disk as a fallback for workloads that exceed memory.

### 06 Stream results

#### Protocol Layer → Client

*Stream results*

Results stream back to the client as they are produced, in columnar form end to end. Execution metrics — per-operator timings, rows read, cache hits, spill volume — are captured in query history for every statement.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.