Turn open tables into sub-second answers
Kubernetes-native lakehouse SQL and AI query engine: 10x faster, up to 50% lower cost, 1,000+ QPS at p95 under 2s, scaling in 1-vCPU increments. No copy into a warehouse, no migration.
What to expect on your workloads
A lakehouse compute engine, not another warehouse
e6 Query engine runs SQL and AI workloads against your existing storage: S3, ADLS Gen2, or Iceberg-managed data. Nothing is copied into a separate system first.
It is built for the three things that make modern analytics hard. High concurrency, when many people run many queries at once. Complex SQL, with joins, window functions, and aggregations over large fact tables. Cost discipline, so you pay for what you use instead of idle infrastructure.
Teams point it at the tables they already govern and keep every dashboard, notebook, and agent exactly where it is.
One engine between your tools and your tables
Dashboards, notebooks, and agents keep their interfaces. The engine executes their heaviest work where the data already lives, in your cloud or your VPC.
QUERY ENGINE
Six things the engine does differently
Each one is a design decision you can check against your own workload during a trial.
01 Sizing and scaling by the vCPU +−
Capacity moves in 1-vCPU increments instead of doubling a cluster. A 20% rise in load costs about 20% more, so you stop paying for headroom you provisioned and never used.
02 No coordinator to bottleneck +−
Decentralized services communicate through defined contracts, so there is no central driver to queue behind and no single point of failure. Concurrency scales out rather than backing up.
03 Complex SQL at full grain +−
Joins, window functions, and aggregations over large fact tables run without down-sampling or pre-aggregating first. The queries your analysts already wrote keep working.
04 SQL and AI on one engine +−
Vector search runs on the same tables as your SQL, with cosine similarity for semantic lookups. There is no second store to sync, govern, and pay for.
05 Autoscaling with a floor and a ceiling +−
Set the bounds and executors track query load between them. No manual tuning between peak and quiet hours, and no latency spike while capacity catches up.
06 Guardrails on runaway queries +−
Set thresholds per cluster and log, alert, or cancel a query in real time before it burns through compute. Cost control happens during the query, not in next month’s invoice.
Built for your heaviest workloads
Move one workload at a time after proving the value for yourself.
Dashboards
BI dashboards that stay fast when everyone opens them at once, served straight off your open tables.
Ad-hoc and interactive
Exploratory queries on full-grain data, without rationing which questions are worth asking.
Scheduled and batch
Reports and jobs that run on compute sized to the query, so idle capacity stops billing you.
Embedded analytics
Customer-facing analytics inside your product, holding SLAs at production scale.
Add it where the bill hurts, keep everything else
e6data runs alongside Databricks, Snowflake, and Trino on the same tables. You move workloads one at a time, and the exit is re-pointing rather than re-platforming.
15M customer-facing queries a day at 60-75% lower TCO
A Nasdaq-listed SaaS leader serves production dashboards straight off open tables, running side by side with the platforms already in place. The bill moved and the SLAs did not.
“We achieved 1,000 QPS concurrencies with p95 SLAs of < 2s on near real-time data & complex queries. Other industry leaders couldn’t meet this even at a far higher TCO.”
You pay for vCPU consumption, not unused compute
Compute is billed on vCPU consumption, sized in 1-vCPU increments. There is no per-query surcharge and no charge for idle headroom, because capacity tracks load instead of stepping up in blocks.
Book a demo for pricing.
It plugs into the stack you already run
Query engine questions
Plain answers for the evaluator in the room.
Do I have to migrate anything?+−
No. The engine reads your existing tables in place, so there is zero data movement and no query rewrites. Your catalogs, governance, and BI connections stay as they are.
How does it hold up at high concurrency?+−
1,000+ QPS with p95 under 2 seconds, in production. There is no coordinator acting as a single point of failure, so parallel queries fan out instead of queueing.
What does it do to my bill?+−
Capacity is sized in 1-vCPU increments, so a 20% rise in load costs roughly 20% more rather than doubling a cluster. Customers see up to 50% lower compute cost on the workloads they move.
Can it handle complex SQL, not just simple scans?+−
Yes. Joins, window functions, and aggregations over large fact tables are the design target, at full grain and with no pre-aggregation step.
Where does it run?+−
Serverless, where we manage the compute, or inside your own Kubernetes cluster in your VPC. Both keep your data in your cloud, and on-prem, hybrid, air-gapped, and sovereign environments are supported.
What happens to a runaway query?+−
You set thresholds per cluster, and the engine can log it, alert, or cancel it in real time before it consumes more compute.
Book a demo on your own workloads
Reach out to book a demo, share challenges you're facing, and tell us how this fits into what you're currently working on or thinking about.
Prefer to self-serve? Problems we're solving →