e6data

Overview

e6data's argument is about allocation, not speed alone. A conventional warehouse reserves compute by warehouse size, so every query gets whatever the warehouse was sized for whether it needs it or not. e6data allocates compute per query instead, and its own illustration puts conventional utilisation around 35 per cent against roughly 95 per cent for adaptive allocation.

Whether those figures hold for a given workload is exactly the thing to test rather than accept, and the same applies to the headline claims of ten times faster and sixty per cent cheaper. They are vendor benchmarks. The underlying mechanism, though, is a real architectural difference rather than a tuning claim, and it is most likely to matter where query sizes vary widely and concurrency is high — the pattern that wastes the most reserved capacity.

It runs as a compute engine over an existing lakehouse with no data movement, so it is a layer added to storage you already have rather than a warehouse to migrate into. That makes it comparable to the other query engines in this category rather than to Snowflake or BigQuery.

Stated workloads are high-concurrency, complex SQL analytics and AI workloads, with data analysts, scientists and engineers as the named audience.

One caveat on the documentation: its landing page carried a last-updated stamp of nine months before this was read, and the docs direct detailed questions to an account manager. Public technical depth is therefore thinner than for the open-source engines in this category, and more of the evaluation has to happen through the vendor.

Key features and capabilities

The same headings are used for every query & processing engines entry, so two tools can be read side by side.

Execution model

• Compute allocated adaptively per query rather than reserved by warehouse size
• Runs as a compute engine over an existing lakehouse, with no data movement
• Positioned as an added layer rather than a destination to migrate into

Languages and APIs

• SQL, including workloads the vendor describes as complex rather than simple aggregation

Data sources and formats

• Reads lakehouse storage in place, so existing data stays where it is
• Zero data movement is the central claim of the deployment model

Performance and scale

• Claims ten times faster and sixty per cent cheaper than conventional warehouses
• Utilisation illustrated as roughly 95 per cent against about 35 per cent for fixed allocation
• These are vendor benchmarks: the gain depends on how variable the query mix is

What it suits

• High-concurrency SQL analytics
• AI workloads named alongside analytics
• Aimed at data analysts, data scientists and data engineers

Ecosystem

• Sits alongside an existing lakehouse rather than replacing its storage or catalogue
• Public integration detail is limited; the documentation points to an account manager

Where it runs and what it costs

• Commercial product with no published pricing
• Documentation is public but was last updated nine months before this reading

Pricing

Price on request

Not published. The cost argument is made comparatively — sixty per cent cheaper through better compute utilisation — rather than through rates or tiers, so any saving has to be verified against your own workload and your current bill rather than read off a price list.

Vendor pricing page →

Demos and videos

• e6data documentation Tutorial · docs.e6data.com (the vendor)

About e6data

e6data builds a lakehouse compute engine for SQL analytics and AI workloads, sold commercially. Its public materials lead with comparative performance and cost claims — ten times faster, sixty per cent cheaper, zero data movement — illustrated by a compute-utilisation comparison against fixed warehouse sizing. Documentation is public but shallower than the category norm, with a landing page last updated nine months before this reading and detailed enquiries routed to an account manager. No pricing is published.

e6data.com