Blast Radius Before Approval
Blast radius answers the question every approver must settle before signing a schema change: what else does this touch? On script creation or approval request, DB Studio walks the live target database and computes the full downstream impact, dependent objects, and the services that read them, so sign-off rests on evidence rather than recall. Computation runs in the background and is ready by the time a reviewer opens the request.
Surfaces
A compact chip sits beside each script in Scripts and each request in Approval Requests, showing headline counts, dependent objects, registered consumers, total data size, and a confidence dot (green complete / amber partial / red failed). Clicking opens the full Blast Radius panel.
Panel
- Headline totals, dependent objects, views, foreign keys, triggers, registered consumers, and combined relation size.
- Dependency graph, left-to-right from the changed objects outward: recursive dependent views, inbound-FK tables, triggers and the functions they invoke, partition parents/children, indexes. Edges colored by relationship type; nodes annotated with size and estimated rows.
- Affected-objects table, the same set, flat and sortable (object, kind, relationship, size, rows) for scanning and export.
- Consumers, services, dashboards, and jobs known to read the affected objects, each tagged by provenance: tagged (team-registered) or observed (seen live).
- Risk signals, an incomplete walk (non-PostgreSQL target, permissions error) states its reason plainly, and any statements the analyzer could not resolve are listed for manual review.
Honesty Contract
Blast radius never fabricates a number and never blocks an approval. When impact cannot be fully computed the report is marked partial or failed with the specific reason, an incomplete graph is itself a signal, and an over-confident wrong radius would be worse than none.
AI Summary
On AI-enabled licenses, Explain this impact generates a plain-English description grounded strictly in the computed report (objects, sizes, consumers, confidence) and instructed never to invent detail; a partial/failed report yields a summary that says so. It is a reviewer aid, not a replacement for the graph and numbers.
Registering Consumers
The consumer list is most valuable when the team declares which services depend on which objects. From Connections, open the consumers icon on a connection row and register the services/dashboards/jobs that read each object. Tagged consumers are stored per connection and surface in every future report for those objects.
Usage Sampler (Observed Consumers)
Beyond hand-registered consumers, the usage sampler infers them from live activity: an opt-in, per-connection background process (Enterprise) that reads active sessions on an interval (default 60s), maps each query to the objects it touches, and records the client application name as an observed consumer. Toggle it in the Object Consumers panel; Sample now captures immediately.
Observed consumers are labeled as such and honest about limits: the sampler only sees queries running during a sample, so infrequent jobs may be missed, and behind a pooler the application name is the pooler's unless clients set it. Consumers unseen for 30 days grey out and drop from the totals, a service that stopped reading is no longer downstream. PostgreSQL-compatible only; observed consumers can be forgotten from the same panel.
Dialect Support
The in-database dependency walk is implemented for PostgreSQL and PostgreSQL-compatible engines (including TimescaleDB). Other dialects return partial with the database-agnostic consumer radius rather than a fabricated graph. Graph-size cap and statement-timeout knobs are documented under Configuration.