Accelerate Splunk Dashboards with tstats and Data Models

Slow dashboard panels often come from searching raw events. A search like `index=foo sourcetype=bar | stats count by host` forces indexers to read and decompress every matching event before aggregating. As index volume grows, that work repeats on every panel refresh.

Useful takeaway: enable acceleration on a Splunk data model and run aggregations with `tstats`. The command reads precomputed summary buckets instead of raw events, which reduces indexer scan volume for supported queries.

How accelerated data models work with tstats

An accelerated data model precomputes aggregates for its root events and child objects. Splunk stores these summaries in tsidx buckets on the indexers. When you run `tstats`, Splunk scans those buckets rather than the original raw event data. Search-time extractions, calculated fields, and lookups are not available unless the fields are indexed or defined in the accelerated model.

Worked configuration and query

Enable acceleration in Splunk Web under Settings > Data Models, or in `data_models.conf`:

[my_data_model]
acceleration = true
acceleration.earliest_time = -7d
acceleration.cron_schedule = 0 2 * * *

Apply this on the search head or search head cluster deployer, depending on how you distribute apps. The user needs admin or a role with data-model editing permissions. Changes made in Splunk Web apply without a restart; configuration file changes may require a reload or restart.

Before, a raw-event scan:

index=foo sourcetype=bar | stats count by host

After, against an accelerated data model object:

| tstats count from datamodel=MyDataModel:MyObject by host

Replace `MyDataModel` and `MyObject` with your model and object names. If you are querying indexed fields directly rather than a data model object, use the `where` clause:

| tstats count where index=foo sourcetype=bar by host

Run searches in the Search & Reporting app. The role running the search needs permission to use `tstats` and read the target indexes.

Verify the result

Open Job Inspector after running either search. Compare `scanCount` and execution time. A successful `tstats` query should show a much smaller scan count than the equivalent raw search over the same time range. Check acceleration status under Settings > Data Models; the state should reach 100% before you rely on the summary for complete results.

Attribute	Raw stats search	Accelerated tstats search
Data scanned	Raw events	Precomputed tsidx summaries
Search-time lookups	Supported	Not supported unless fields are indexed
Backfill required	No	Yes, before results are complete
Best for	Ad hoc investigation	Repeated dashboard aggregations

Limits and common mistakes

• High-cardinality split-by fields such as `user_id` can make summaries too large and degrade indexer performance.
• Search-time calculated fields, lookups, and regex extractions are unavailable unless the fields are indexed or part of the model.
• Newly indexed events appear only after the next backfill or real-time acceleration cycle.
• Piping `tstats` into `lookup` or `eval` on non-indexed fields forces full event retrieval and negates the performance gain.

Rollback

Enabling acceleration changes system state because it creates summary files on indexers. To roll back, disable acceleration in Splunk Web or set `acceleration = false` in `data_models.conf`. This stops new backfill, but existing summary data remains on disk until retention removes it.

Practical verification before production use

Run `| tstats count where index=_internal by sourcetype` and inspect Job Inspector. Then run the equivalent raw search over the same fixed time range and compare execution time. Confirm the data model acceleration status reads 100% in Splunk Web. Repeat the comparison for a dashboard panel before and after enabling acceleration. Verify this behavior in your environment, because summary size and backfill load depend on your data volume and field cardinality.