Understanding Data Architecture in Dynatrace Managed: How is indexing handled?

Aboud1 — Mon, 08 Jun 2026 06:29:47 GMT

Hi everyone,

I have a quick architectural question regarding Dynatrace Managed.

I know that Dynatrace SaaS leverages Grail for a schema-less/index-less architecture. However, since Dynatrace Managed traditionally runs on Elasticsearch and Cassandra, I want to better understand how data handling works under the hood here.

How does Dynatrace Managed achieve high-speed, flexible queries on historical data (like Traces and RUM) without the typical heavy indexing overhead and storage bloom seen in traditional index-based tools?
Are there any automated data optimization patterns or "schema-on-read" behaviors happening even within the Elastic/Cassandra layer?

Just trying to deeply understand the underlying philosophy for our Managed deployment.

Thanks in advance for your insights.

BR,

Aboud

Re: Understanding Data Architecture in Dynatrace Managed: How is indexing handled?

Aboud1 — Tue, 09 Jun 2026 09:44:24 GMT

UPDATE:

Hi everyone,

I wanted to share an update on this since I opened a technical ticket with the Dynatrace Support team to get a definitive answer for our Managed environment. Here is the architectural breakdown they provided regarding how data indexing and historical queries are handled under the hood:

Zero Manual Overhead: In Dynatrace Managed, all data structures and indexes are fully predefined and optimized by the platform out-of-the-box. There is no manual schema or index management required from the user/admin side.
Two-Tier Querying Mechanism: To keep performance fast without the typical storage bloom or heavy indexing overhead of traditional tools, Dynatrace uses a smart scoping strategy. For any historical query, the engine first leverages indexed low-cardinality dimensions (like Service or Application) to instantly narrow down and scope the dataset.
High-Cardinality Flexibility: Once the dataset is scoped, it performs deeper scans on the high-cardinality data (such as RUM sessions, traces, or logs). While unscoped high-cardinality queries can relatively be slower, this architecture architecture gives full flexibility to explore "unknowns" and perform deep analytical troubleshooting.
Data Lifecycle: Data is continuously aggregated over time and retained based on the configured retention periods to maintain optimal storage and cluster performance.
Grail Roadmap: As of now, there is no official GTM (Go-To-Market) announcement regarding bringing the Grail architecture to the Managed/Private Cloud platform.

Thought of sharing this here so anyone running Dynatrace Managed can benefit from this architectural clarity✌️

topic Re: Understanding Data Architecture in Dynatrace Managed: How is indexing handled? in Dynatrace Managed Q&A

Understanding Data Architecture in Dynatrace Managed: How is indexing handled?

Re: Understanding Data Architecture in Dynatrace Managed: How is indexing handled?