Dash0 Raises $110M Series B at $1B Valuation

Last updated: May 7, 2026

Resource Storage & Query Behavior

How Dash0 stores merged resources and query behavior for resource attributes.

This page explains how Dash0 stores merged resources and how to query resource attributes effectively.

Note

For practical examples of resource fragmentation and how Dash0 resolves them, see Why Resource Equality? For platform-specific equality rules, see References.

Storage Architecture

Understanding how Dash0 stores resource attributes is essential to understanding query behavior and limitations.

Resource equality rules assign a dash0.resource.id to telemetry based on matching attribute patterns. When multiple resource dictionaries share the same resource ID, Dash0 stores them separately with different dash0.resource.hash values.

Each resource is stored with:

  • Resource ID: A resource attribute added by Dash0, specifically, dash0.resource.id
  • Resource Hash: A resource attribute added by Dash0, specifically, dash0.resource.hash
  • All attributes: The complete attribute set from that telemetry source

When displaying or querying resources, Dash0 aggregates attributes across all matched resource dictionaries using different strategies depending on the query interface:

  • Storage queries: Use anyLast aggregation (returns the most recently seen value)
  • OpenTelemetry queries: Use maxMap aggregation (returns all values as a map)
  • Prometheus queries: Use semicolon-concatenation (returns all values joined by ;)
Note

In Prometheus, INFO metrics carry "shared labels" about components (e.g., node_uname_info), requiring join operations with group_left. OpenTelemetry resources solve this more elegantly by attaching metadata directly to telemetry at collection time, eliminating the need for join operations.

Query Behavior

Resources that share the same identifier can be queried as a unified view, even though their attributes are stored separately.

When viewing resources in the Map or Resource pages, telemetry from multiple sources is correlated using equality rules. Resources that share the same dash0.resource.id are stored separately but can be queried as a unified view.

Understanding how queries work across merged resources:

ScenarioResource 1Resource 2Query Behavior
Attribute missing in bothunsetunsetNo match
Present only in firstvalueunsetMatches attribute = value
Present only in secondunsetvalueMatches attribute = value
Same value in bothvaluevalueMatches attribute = value
Different valuesvalue1value2Matches attribute = value1 OR attribute = value2

Key behaviors:

  • Attribute existence: Matches if a resource with this ID has the attribute
  • Attribute value: Matches if a resource with this ID has that specific value

Example queries:

  • Finding resources that changed teams: Query for team = A AND team = B to find resources where the team attribute changed during the time range
  • Multi-team ownership: A Kubernetes pod with a service mesh sidecar may have attributes from both the platform team (sidecar) and application team (main container). Both teams can find their resources using their respective attribute queries
  • Querying Lambda functions by region: Use dash0.resource.type == "aws.lambda.function" AND cloud.region == "us-east-1" to find all Lambda invocations in a specific region
  • Finding Cloud Run instances: Query dash0.resource.type == "gcp.cloud_run.service" AND faas.name == "my-service" to see all instances of a specific Cloud Run service
Tip

The dash0.resource.type attribute is automatically assigned based on resource equality rules. See References for complete type assignments.

Limitations and Considerations

While resource equality handles most scenarios automatically, there are some behaviors to be aware of when working with multi-container pods or complex attribute configurations.

Dash0 does not implement namespace-aware conflict detection. When multiple containers in a pod report different values for the same attribute name (e.g., service.name=app vs service.name=envoy), both values are stored and queryable.

Why this matters: If you query for service.name = app, you'll get telemetry from all containers in pods where at least one container has service.name=app, even if other containers have different service names.

Workaround: To target specific containers, include additional identifying attributes in your query:

1
service.name = app AND container.name = main-app

To target telemetry from specific containers or processes within a multi-container pod, include identifying attributes like container.name, process.runtime.name, telemetry.sdk.name, or custom attributes that uniquely identify the source.

Further Reading

For related concepts and implementation details, explore the following resources.

Dash0 Guides & Knowledge

OpenTelemetry Resources