The Dashboard That Broke at the Moment It Mattered

The interesting thing about a slow dashboard is when it decides to become slow. It can behave perfectly in a meeting, with one executive clicking through the charts. Then the customers arrive. For one high-growth fintech described in an e6data case study, those customers were more than 18,000 merchants who might pay to see their own transaction data. The company had the data, and the idea had a plausible revenue line. What it lacked was a query engine that could survive the crowd.

Its existing setup struggled as traffic approached 1,000 queries per second. The 95th-percentile response time - the slowest experience among nineteen of every twenty requests - drifted beyond a two-second target. Adding capacity made the infrastructure bill swell, but still failed to produce the service level the product needed. The merchant dashboard remained a pilot. It is an unusually clear account of a common enterprise embarrassment: a feature that costs more precisely when it becomes popular.

The peak is the product

e6data's answer was to pilot its compute engine beside the fintech's existing engines, on a selected workload. The data remained in the customer's AWS S3 lakehouse, with AWS Glue as the catalog. In the company's account, the new setup sustained more than 1,000 QPS with p95 below two seconds, including complex joins. It also reports query completion up to twelve times faster across a mix of analytical and near-real-time work, and total cost more than 50% lower than the former engine. The dashboards then shipped as a premium merchant feature.

Company-published results from one anonymous fintech pilot; workload and comparison engine matter.

That is the claim, and it is also a useful way to understand the company. e6data does not ask a buyer to begin with a heroic reconstruction of the whole data estate. Its query product sits between familiar tools - BI dashboards, notebooks and applications using standard interfaces - and open tables such as Apache Iceberg, Delta Lake and Hudi. It can run in a customer's cloud or private environment. The operational promise is that a team can point a difficult slice of traffic at a second engine and compare the result before making a larger commitment.

Why one extra query can cost a whole new cluster

The odd economics of analytics are easiest to see when demand rises by an inconvenient amount. Many systems add compute in coarse steps: a cluster size, a node, a capacity tier. If the next step is much larger than the extra work, buyers pay for idle headroom. e6data says its architecture separates planning, metadata work and execution, allowing components to grow independently in one-vCPU increments. It also avoids a single central coordinator, a design choice intended to prevent one planner from becoming the queue everyone waits behind.

There is no magic in the unit alone. A tiny increment is useful only if the engine can assign work quickly, keep data movement modest, and maintain the response time that customers notice. Its engineers describe vectorized execution and reducing network shuffle as part of that effort. The practical payoff should appear in a load test: as the crowd grows, does p95 stay put, and does the cost curve rise smoothly? If either answer is no, the architectural poetry is of limited use.

The public price gives the argument a concrete starting point. e6data lists a pay-as-you-go Query Engine rate of $0.175 per vCPU-hour, as well as custom outcome-based contracts and bring-your-own-cloud licensing. In its managed plan, the company says the rate includes infrastructure and license; in a customer-cloud arrangement, cloud resources are paid to the provider and e6data charges for its software. The comparison that matters is the complete workload bill, measured over busy and quiet hours, with an agreed latency target.

A new engine without a new address

Open table formats have made a particular kind of experiment possible. If data already lives in Iceberg, Delta or Hudi, another engine can in principle read it without a bulk copy. e6data has built its position around that opening. In 2025 it described expanded support across those formats and Apache Polaris, and showed a Microsoft Fabric integration that queries OneLake data directly. The company reported a 33% performance improvement in that Fabric test after optimization. These are its own measurements, but the basic arrangement is easy to grasp: leave the governed tables where they are, change who does the reading.

Start with one workload. Keep the catalog, storage and tools in place.

Chargebee is a named example. Its COO, Rajaraman Santhanam, said the company worked with e6data on internal and external analytics atop its lakehouse and supported more than 1,000 QPS on complex, near-real-time queries while keeping client latency under two seconds. Freshworks has also publicly discussed evaluating e6data on heavy workloads. These references establish why the company is interesting to enterprise buyers, though they do not turn every advertised speed multiplier into a universal result. Query shape, freshness, governance and existing platform costs differ too much for that.

“We don't treat object stores like cold storage.”Sudarshan, e6data founding engineer and head of engineering

The engine is becoming a shelf

The original story is compute. The current catalog is wider. e6data's Ingest Engine collects database changes, streams, files and application events, transforms them in flight, and writes them to open tables or other destinations. Its product page describes a path to query-ready Iceberg tables in roughly 15 seconds and says a single production pipeline has handled more than a million events per second. AgentFlow tackles a different bottleneck: it turns a described business workflow into a versioned sequence of smaller, scoped agents, with defined tools and checks. On one five-step comparison, the company reports 94.7% fewer total tokens than an interpreted agent runtime using the same workflow.

The expansion is understandable. A dashboard's two-second clock starts long before the query runs. The records must arrive, the table must remain healthy, the catalog must be current, and an AI agent may ask dozens of questions where a person asked one. e6data is trying to own more of that path. Whether customers want the full shelf or only its query engine is a commercial question, not a technical theorem. Its present advantage is that each piece can be tested on a bounded job.

A modest first move with an immodest test

The company was founded in 2020 by Vishnu Vasanth, Adishesh Kishore and Srinath Prabhu, according to investor and company profiles. Accel led a $10 million Series A in September 2024, with Beenext participating. The business now sits among enormous alternatives - Snowflake, Databricks, Microsoft Fabric, Amazon Redshift and self-operated Trino - all of which have their own strengths and customer habits. e6data's distinction is specific: a format-neutral compute layer with granular scaling, sold to teams whose existing engine becomes costly or slow under difficult loads.

For a buyer, the lesson from the fintech case is wonderfully unromantic. Find the dashboard that falters when customers actually use it. Record p95 and p99 latency, concurrency, data freshness and the full bill. Run a second engine on the same tables, then repeat the test at the hour everyone dreads. If the workload is small, steady and already cheap, the case for another engine may be thin. If the data is locked in a proprietary arrangement or the team cannot operate another query path, adoption becomes harder. But when a live analytics feature is stuck between a missed service level and an extravagant capacity tier, a one-workload trial is a sensible experiment. The crowd, after all, is not going to make an appointment.