$3M+ saved annually in customer-facing analytics
A NASDAQ-listed SaaS company with 68,000+ customers serves 10 million+ in-app dashboard queries a day on one lakehouse. TCO fell by ~60% once fully deployed, with zero-failure SLAs intact.
"The moment e6data was able to meet the web SLAs, it became a very easy decision to make one data lake that serves both web and non-web, using e6data as a query engine."
One lake for web and non-web
The bake-off ran e6data against three other engines on real production traffic. The web SLA was the bar; the bill was the tiebreaker.
The stakes
In-app dashboards serving 10 million+ queries a day, on highly normalized data with 10+ table joins per query, against a sub-2-second p95 requirement. Customer-facing analytics is the product, not a feature.
The wall
Compute cost doubled every 18 months on the incumbent engine. The team also wanted a lakehouse architecture for AI and ML use cases, interoperability, and an exit from vendor lock-in, without giving up functionality.
The evaluation
Before committing, the team set the bar: the criteria that would decide it - p95 latency under real concurrency, cost at scale, security and private-link connectivity, and ease of adoption - measured on their own data rather than synthetic benchmarks.
The bake-off
Four engines, five criteria: performance, zero-failure SLAs, cost, ease of adoption, and security including private link connectivity. Evaluation started on data exports, then replayed tens of millions of production queries against the dashboard workload.
The result
p95 went from 30 seconds in early testing to 1.5 to 2 seconds at 60 QPS peak, with every failure SLA met. TCO fell ~60%, worth $3M a year fully deployed, and one lakehouse now serves web dashboards and exports from the same tables.
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 →