Setting the file. One moment.
Subchapter 23.5
references/querying-data/ddsql/datastores.mdMarkdown3 KBView on GitHub
Use this when a Datadog App needs to query a Datadog App datastore from backend code.
Prefer DDSQL for datastore reads that need projection, filters, sorting, pagination, counts, grouping, or derived fields. Use datastore actions directly for writes, deletes, simple single-item reads, or workflows that need action-specific behavior rather than SQL-shaped data retrieval.
Public docs:
Before writing view queries:
LIMIT.Stop and inspect more if the datastore ID, columns, or key fields are not known.
This is an observed DDSQL query shape, not a substitute for schema/spec discovery. Before generating app code, confirm that the current environment exposes dd.actions_datastores, inspect its required arguments and column typing, and validate a minimal bounded query.
SELECT key, summary, status
FROM dd.actions_datastores(
id => '<datastore-id>',
columns => ARRAY ['key', 'summary', 'status']
) AS (
key VARCHAR,
summary VARCHAR,
status VARCHAR
)
WHERE status = 'Open'
ORDER BY key
LIMIT 100;Use the pattern this way:
WHERE, ORDER BY, LIMIT, and aggregates into DDSQL where supported.Use DDSQL to avoid treating a datastore as a full export source:
LIMIT, pagination, or virtualization.This replaces the slow pattern of loading the full datastore into the browser, building a local database, and querying it client-side.
ORDER BY fields.For exact backend execution imports, prefer the generated app project’s AGENTS.md and installed package APIs over examples from memory.