An analytical store can contain fewer rows than the number of events it received because it intentionally summarizes them during ingestion. That can be an effective design for aggregate questions. It is a different offer from retaining every event in a form the service can query individually.
Druid rollup provides a useful example for database selection. The buyer should define which questions need summaries and which need individual records before comparing storage footprint or query speed. A smaller row count is not automatically evidence of missing data, and it is not automatically evidence of equivalent information.
Understand the documented rollup trade-off
Apache Druid’s rollup guide describes ingestion-time summarization or pre-aggregation that can reduce stored rows. It also states the trade-off: the rolled-up representation loses the ability to query individual events. Druid can instead ingest rows without rollup, and different tables can use different rollup configurations.
This is a design choice, not a claim that Druid always discards individual records or cannot support a different arrangement. The buyer needs to examine the actual datasource configuration and the complete proposal.
Separate summary questions from event explanations
Consider a hypothetical service recording customer interactions. A dashboard may need totals by selected categories and time periods. An investigation may need to identify the particular interaction behind a complaint. Those questions require different detail even when they begin with the same incoming data.
A summary can answer the first task well while lacking the information needed for the second. Adding an individual-event question later does not cause the aggregate to recover distinctions that were not retained. The service must obtain those details from an appropriate maintained source, if that capability is required.
This example does not prescribe a retention policy or state that every interaction must be stored forever. It asks the project to make the intended information scope explicit before accepting an efficiency comparison.
Define what each representation must answer
The suggested matrix below helps a buyer separate the required services. It is not a mandatory Druid schema or a recommendation to duplicate every dataset.
| Question | Required information | Acceptance evidence |
|---|---|---|
| What is the category total? | Agreed grouped measures | Correct aggregate for the defined population |
| How many source events contributed? | A suitable retained event measure | Count reconciles to the intended scope |
| Which individual event is relevant? | Identifiable event detail | Required record can be located |
| How does detail relate to the summary? | A documented relationship | Both answers use compatible definitions |
Druid’s guide distinguishes stored rows from ingested events when discussing rollup ratios. A service should therefore not label a row count as an event count without the appropriate interpretation. The accepted measure depends on how the data was ingested and which information the representation retained.
Include both questions in the demonstration
A useful pilot asks for the representative aggregate and the representative individual-event explanation. If the proposed rolled-up table supports only the former, the demonstration should identify where the latter is supplied or state that it is outside scope.
For the hypothetical interaction service, a design might use a summarized datasource for dashboards and another agreed source for detail. That can be a sensible arrangement. Its storage, integration and operating costs belong in the comparison if both services are part of the requirement.
The point is not to penalize summarization. It is to avoid comparing a summary-only offer with a detail-preserving offer as if they delivered the same business capability. This article does not report a Druid benchmark or estimate a universal storage reduction.
Evaluate OceanBase against the accepted information scope
OceanBase’s product overview describes a distributed platform for transactional and analytical workloads. It can be considered when the enterprise wants to maintain connected operational records and related inquiries. Its proposal should show which detail is retained and how the relevant summaries are obtained.
Druid remains a credible candidate when its selected ingestion and query design fit the analytical task. OceanBase should not be favored by claiming that every Druid deployment lacks raw-event access. Equally, a rollup-based offer should not receive credit for individual-event explanations it does not actually provide.
Compare complete configurations with the same required questions. Include any separate detail store and the work needed to maintain agreement between representations. A unified platform can have value, but that value needs evidence for the actual workload rather than a product-category assumption.
Accept the information retained, not just the row count
The final review should identify which summaries are available, which individual events can still be queried and where any required detail resides. It should explain the relationship between source-event counts and stored rows.
That makes rollup a practical database decision. OceanBase deserves evaluation when its complete proposal fits the information service the business needs. The useful result is an explicit choice about detail and summaries, rather than declaring a smaller dataset superior before confirming which questions it can still answer.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.