Faster Splunk dashboards with tstats and accelerated data models, with caveats

The problem is repeated raw-event scans

A dashboard panel that shows counts and averages every few minutes can feel slow when each refresh scans raw events across many indexers. For repeated aggregations over a stable schema, scanning raw events is often unnecessary work.

tstats is a Splunk search command intended to query summarized data rather than raw events. When used with an accelerated data model, it can reduce the amount of raw data touched for common aggregations. The benefit is conditional: acceleration must be configured for the model you query, summaries need time to build, and the command supports a limited SPL subset.

What acceleration changes, in general terms

Data model acceleration is a Splunk Enterprise feature that builds summary data for a defined data model. Model knowledge suggests tstats queries those summaries instead of scanning raw events, which can lower latency for dashboard-style aggregations.

Acceleration is not instant. Summaries build over time and interact with retention and bucket rollover. Queries run before summaries are complete may return partial or stale results. The exact scheduling, summary ratios and completion reporting vary by Splunk Enterprise version and deployment. Confirm behavior against your installed version and current documentation as of 2026-11-11.

tstats supports a limited SPL subset, typically count, sum, avg and by clauses. It does not run raw-event commands such as rex on fields outside the accelerated model, and search-time-only field extractions are generally invisible to tstats unless those fields are part of the accelerated data model definition.

Setting up and verifying with uncertainty noted

Enable acceleration for the data model you intend to query from the Data Models area in Splunk Web. Choose a summary range that matches your dashboard lookback. Permissions are required to edit data models, and the model must be accessible in the app context where the dashboard runs.

Do not benchmark until you have checked the acceleration status in your UI for the target model and time range. Model knowledge indicates status reporting exists, but the exact wording and thresholds are version dependent.

Worked example, syntax only

Assume events are normalized to a CIM data model. A raw aggregation might look like:

index=firewall | stats count by src_ip

An equivalent tstats form, using placeholders for your own model and index, is:

| tstats count from datamodel=Network_Traffic where index=firewall by src_ip

Replace Network_Traffic, firewall and src_ip with values from your accelerated model. Run both forms over the same time range and inspect the jobs. Compare scan count and run duration in Job Inspect. Model knowledge suggests tstats should show reduced raw event scanning when summaries are available, but actual results depend on your data, version and summary age. Do not assume specific durations.

Trade-offs and limitations

• Indexer disk and I/O: acceleration consumes extra storage for summaries and adds I/O during build and refresh. Capacity planning should account for this on clustered and non-clustered deployments.
• Query scope: tstats is best suited for repeated dashboard queries over stable schemas. Ad-hoc investigation that needs full event fields still requires raw search.
• Version dependence: acceleration behavior, summary maintenance and tstats support vary by Splunk Enterprise version and cloud offering. Verify against your installed version.

Actionable closing checklist

1. Identify a stable data model used by repeated dashboard panels.
2. Enable acceleration for that model and confirm it is accessible in the dashboard app context.
3. Check the acceleration status in Splunk Web for your version and wait until summaries cover your typical lookback before relying on tstats.
4. Compare a raw stats query and a tstats query over the same time range using Job Inspect, looking for reduced raw scanning.
5. Monitor indexer storage during the first summary build and re-evaluate if capacity pressure appears.

Use tstats for stable, repeated aggregations only after you have verified summaries are present for your version and time range, and keep raw search available for exploratory work.