Datadog SQL Query
To run a datadog sql query workflow, link the agent to a read role. That role reads metric views and sends statement stats to your dashboard. Most teams start by creating one database user for the monitoring agent. They grant that user permission to read system tables and performance views. When teams rush this step, they often grant broad read rights across schemas. Broad permissions let the agent or shared roles read sensitive user rows. How a datadog sql query setup works in practice The m
SQL Query Filtering + Datadog Security Monitoring: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To run a datadog sql query workflow, link the agent to a read role. That role reads metric views and sends statement stats to your dashboard. Most teams start by creating one database user for the monitoring agent. They grant that user permission to read system tables and performance views. When teams rush this step, they often grant broad read rights across schemas. Broad permissions let the agent or shared roles read sensitive user rows.
How a datadog sql query setup works in practice
The monitoring agent runs on a host or inside a container near your database. It uses a local database account to poll system views on a schedule. Those system views store query text, run counts, wait times, and lock stats. Before sending text out, the agent strips literal values from each statement. This step turns raw statements into normalized digests with placeholders for numbers and strings.
Your team can also collect execution plans for slow or heavy queries. The agent samples live runs and asks the database to explain the plan. It then sends the plan tree, cost metrics, and row estimates to the dashboard. Engineers use these digests to spot missing indexes and high load spikes. They filter statements by host, database name, wait event, or total run time.
Why monitoring roles need strict table boundaries
A monitoring role only needs to read system stats and engine views. It should not have read rights on customer tables or billing records. Yet many teams reuse an existing app role or admin account during setup. When a shared role has wide permissions, two problems show up fast. First, plan collection or custom metric queries can touch real business tables. Second, engineers often copy those same credentials into local tools to debug slow runs.
Splitting roles between the agent and human engineers reduces this risk right away. Give the agent a dedicated login that only reads engine stat views. Give developers separate logins when they need to test a slow query by hand. Even then, native database roles only check who logs in at the start.
SQL Query Filtering + Datadog Security Monitoring: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native database roles solve and what they miss
Native database roles and grants control which tables a user can read or change. Coupled with query dashboards, they tell you how your database performed a minute ago. You can see which query digest caused a spike in CPU or disk wait. You can also see which database role ran that workload at the time.
Still, monitoring tools only watch from the outside after a statement starts or ends. And native roles cannot inspect individual queries in flight to block risky commands. Once an engineer logs in to fix a slow query, the role stays wide open. A single mistyped update or unfiltered select can lock tables or expose private rows. Dashboards will record the outage, and raw results can still show emails or card numbers. Closing that gap requires checking each statement and masking sensitive fields like phone numbers in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does query monitoring expose raw customer data in dashboards?
Standard agent collection strips literal strings and numbers from query text before upload. Still, custom metric queries can pull raw values if you query user tables directly.
What database permissions does the monitoring agent need?
The agent only needs a login that can read system performance and stat views. It does not need write rights or read permissions on business data tables.
Why do engineers still need live database access when they have query metrics?
Dashboards show historical digests and sample plans, which helps teams find the slow query. Engineers still log in to test index changes, check live locks, or fix bad data.