Real-Time Analytics Store

This category exists because of a gap neither side of the traditional split covers. A data warehouse gives excellent analytical queries with minutes-to-hours freshness and modest concurrency. An operational database gives millisecond point lookups and falls over on aggregate scans. A customer-facing dashboard needs aggregates over billions of rows, in under a second, at thousands of concurrent users, on data seconds old.

These stores get there through a consistent set of choices: columnar storage with aggressive compression, pre-aggregation or materialised rollups computed at ingestion, indexes tuned for filtered aggregation, and ingestion designed to make data queryable within seconds rather than committed in large batches.

The trade-offs to state plainly when proposing one. Joins are limited or expensive, so the data model is usually denormalised at ingestion, which pushes complexity upstream into the pipeline. Updates and deletes are awkward, which matters for correction and for erasure requests. And it is another system to operate, with its own scaling and failure characteristics.

The question that decides whether it is justified: is the query volume driven by users or by analysts? User-facing analytics at scale is what this category is for; internal reporting almost never needs it, and the warehouse plus a caching layer is cheaper and simpler.