The request path
When you run a query against a cluster:- Connect. Your tool connects over TLS to a single e6data endpoint and names the cluster to run on. You never address individual nodes - e6data routes the request.
- Authenticate. e6 query engine verifies your token and resolves your identity and permissions.
- Plan. The cluster’s planner evaluates the whole query holistically, resolves table metadata from your catalog, and builds an optimized execution plan - combining heavy operations into single stages and running independent branches in parallel.
- Execute. Executor nodes read data directly from your object storage (S3, ADLS Gen2) and run the plan. e6data builds layers of indirection on the fly that cut the volume of data actually scanned, reducing network shuffle dramatically on large queries.
- Return. Results stream back to your client.
Where things run
See Platform components for the breakdown of each plane.
What makes it scale
- Consensus-based distribution. There’s no single-point-of-failure coordinator, so the engine scales horizontally.
- Kubernetes-native. Clusters auto-scale to meet demand and suspend when idle.
- Plan-then-execute. Evaluating the whole query before running it means less wasted work as data volume and query complexity grow.