Query Insights and tags

Purpose

Use PlanetScale Insights to understand query behavior, then recommend SQLCommenter-compatible tags that make future diagnosis and Traffic Control possible. Do not change database settings or repository code without approval.

What to inspect

Query behavior

For the selected database and branch, inspect:

• Top queries by total time.
• Top queries by time per execution.
• Top queries by rows read.
• Top queries by execution count.
• For Postgres, top queries by CPU usage (sort=cpuTime or

sort=percentCpuTime on the Insights API).

• Queries with errors.
• Notable queries and active anomalies.
• Query patterns affected by recent deploys.
• Query patterns attached to schema recommendations.
• For sharded Vitess databases, vindex usage for each query pattern: the

percentage of traffic using relevant vindexes and the vindex-usage trend over time. The API exposes per-pattern indexusages and routingindex_usages; get the trend from the dashboard Vindexes tab or by comparing API windows. Treat missing or declining relevant-vindex usage as an indexing or routing investigation input, not as proof that a new index is required.

Insights API surface

Query Insights is public API: read-only GET endpoints under organizations/{org}/databases/{db}/branches/{branch}, authorized by a service token or OAuth token with readdatabases/readdatabase.

• /insights — aggregated statistics per query pattern over the requested

window. Set the window with from/to (ISO 8601) or period (for example 1h, 24h); search SQL patterns with q; sort server-side with sort and dir — sort keys include count, errorCount, rowsRead, totalTime, cpuTime, ioTime, percentTime, percentCpuTime, p50Latency, p99Latency, maxLatency, egressBytes, and the trafficControlWarnings/trafficControlThrottled family. Filter with tablettype (primary, replica, rdonly) and type (SELECT, INSERT, UPDATE, DELETE); trim responses with fields; paginate with page/perpage.

• /insights/{fingerprint} — individual collected executions for a

pattern (timestamps, duration, rows, username, client address, error message). Available regardless of raw query collection; raw collection adds literal parameter values to these records. /insights/{fingerprint}/summary returns the single-pattern aggregate; /insights/queries/{id} fetches one execution.

• /insights/errors — error fingerprints with counts and messages (q

searches the error message; sort by count, lastRun, totalTime, or timePerQuery). /insights/errors/{fingerprint} lists the failing executions behind one error fingerprint.

• /insights/anomalies and /insights/anomalies/{id} — anomaly windows

with per-query correlation coefficients identifying which patterns moved with the anomaly.

• /insights/tags — tag keys with observed values (values_limit,

literalvaluesonly, and fingerprint/keyspace filters); /insights/tags/{tag} for a single key. /insights/tags/summaries groups the full statistics schema by one or more tag keys via the tags parameter — use it to attribute load to routes, jobs, or features without client-side aggregation.

• /insights/{fingerprint}/traffic/budgets — the Traffic Control budgets

and rules that affect a fingerprint (Postgres).

Aggregates cover the requested window. Duration fields use names like sumtotaldurationmillis, with explicit share-of-window percent fields (sumtotaldurationpercent); both totals and percentages are reliable for the window requested.

The response schema is shared across engines, but some fields are engine-specific: CPU/IO durations and block-cache statistics (sumcpudurationmillis, blocksread, blockcachehitratio, …) are populated for Postgres; shard queries, keyspaces, tablettype, and routing-index (vindex) usage are populated for Vitess.

Tag coverage

For each expensive or anomalous query, determine:

• Is it tagged?
• Which service produced it?
• Which route, job, controller, or action produced it?
• Which deployment SHA produced it?
• Is the tag cardinality safe?
• Are tags consistent across frameworks and languages?
• Use the tags API to answer these questions: /insights/tags shows which

keys and values are present, and /insights/tags/summaries?tags=... attributes load per tag value. In the Vitess dashboard, filter the query table with tag:key:value and drill into query details to see tags on individual executions. Built-in query metadata and SQLCommenter tags are both valid attribution sources.

Raw query collection

Check whether raw query / complete query collection is enabled. On Postgres the effective state is the pginsights.rawqueries cluster parameter (per branch, dashboard Extensions tab, default false); the database API object's insightsrawqueries field is a separate surface. When the two differ, report the cluster parameter as the effective state and do not describe the difference as an inconsistency. On Vitess there is no cluster parameter; the database API's insightsraw_queries field is the effective state.

Report it as a capability state, not a risk posture. Raw query collection records literal parameter values per execution, which pattern-level Insights data does not provide. It is the mechanism for isolating which specific invocation of a pattern is pathological. Execution-level records are retrievable from /insights/{fingerprint} with or without raw collection; raw collection adds the literal parameter values to those records.

When it is disabled, the finding is a capability gap: identify the query patterns in this assessment where pattern-level data is insufficient (unexplained latency variance within a fingerprint, tenant- or parameter-dependent behavior) and state that raw collection would resolve them. State the operational property once, as fact: literal values become visible to the observability pipeline. Where the customer's data-handling requirements constrain this, scoped enablement (incident windows, defined retention) and leaving collection disabled are both valid outcomes — record the rationale rather than a default judgment in either direction.

Tags and raw collection are complementary instruments: tags attribute a pattern to a code path; raw collection identifies the specific invocation. Assessments should evaluate both.

SQLCommenter tag schema

Recommend this baseline tag set:

• application: stable app name.
• service: service or process name.
• environment: production, staging, development.
• route: normalized route template, for example /accounts/:id/orders, not /accounts/123/orders.
• controller: framework controller name where applicable.
• action: framework action name where applicable.
• job: background job class or worker name.
• queue: background queue.
• feature: bounded feature name for traffic classes like export, report, search, billing, checkout.
• release_sha: short git SHA or deploy identifier.
• source: app, worker, script, agent, mcp, bi, integration.
• tenant_tier: free, pro, enterprise, internal, only if bounded.

Do not recommend these tags by default:

• user_id
• request_id
• tenant_id
• email
• session_id
• raw URL
• unbounded GraphQL operation text
• access token
• secret

If the customer needs tenant-level isolation, recommend a bounded abstraction first, such as tenant tier, cell, shard, or customer class. Tenant ID is only acceptable with explicit approval after cardinality and privacy review.

Cardinality rules

Flag a tag as unsafe when:

• Values are unbounded.
• Values include IDs, UUIDs, emails, slugs, or raw paths.
• The same query pattern emits many unique tag combinations.
• The tag would make Insights or Traffic Control aggregation noisy.

Recommend normalizing at the application boundary.

Analysis output

For each top query pattern, produce:

• Fingerprint or normalized query.
• Current metrics.
• Current tags.
• Missing tags.
• Likely source in application code.
• Whether it is a schema recommendation candidate.
• Whether it is a Traffic Control candidate.
• Whether it is an application optimization candidate.

Recommendation classes

Add tags

Recommend SQLCommenter instrumentation when query attribution is weak.

Improve tag normalization

Recommend replacing high-cardinality tags with bounded values.

Add Traffic Control warning budget

For Postgres only, recommend warn mode budgets for expensive but important routes, jobs, analytics, exports, or third-party integrations.

Add schema recommendation workflow

For Vitess, recommend turning open schema recommendations into branch/deploy-request work. For Postgres, recommend turning them into reviewed migrations against a non-production branch.

Fix code path

Recommend a repository PR when the expensive query is caused by N+1, missing pagination, accidental eager load, unbounded export, broad search, or polling.

Safety rules

Do not:

• Enable raw query collection.
• Add tags to code.
• Change Traffic Control budgets.
• Apply schema recommendations.
• Run production EXPLAIN ANALYZE on expensive queries.

Without explicit approval.

Output

Return:

• Query risk table.
• Tag coverage table.
• Bad/high-cardinality tag table.
• Recommended tag schema for this application.
• Candidate Traffic Control slices.
• Candidate schema and code changes.
• Proposed changes requiring approval.

End with:

“No Insights, tag, repository, or Traffic Control changes have been applied.”