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 (a permissions error, a catalog query that timed out, the node limit) states its reason plainly, and any statements the analyzer could not resolve are listed for manual review.

What Each Engine Contributes

The graph is walked from the objects the script changes, read from the script in the engine's own language, through the engine's own catalog:

• PostgreSQL and TimescaleDB, dependent views (recursively), tables with foreign keys to the changed tables, triggers and their functions, partitions and indexes.
• CockroachDB, dependent views, foreign keys and indexes.
• MySQL and MariaDB, dependent views (recursively), foreign keys, triggers, routines that name the table, and indexes.
• SQL Server and Oracle, the views, routines and triggers the database records as depending on the table, foreign keys and indexes.
• SQLite, dependent views, foreign keys, triggers and indexes.
• MongoDB, views built on the collection (including through $lookup, $graphLookup, $unionWith and $facet), indexes and document counts.
• Cassandra, materialized views, secondary indexes, triggers and size estimates.
• Neo4j, the labels linked to a changed label by relationships, the label's indexes (including those behind constraints) and node counts.
• Elasticsearch, the aliases that point at a changed index, and document counts.
• Redis, each key pattern the commands touch, with how many keys match it and the memory they use; Redis keeps no dependencies between keys.

Counts read rows on relational engines, documents on MongoDB and Elasticsearch, nodes on Neo4j and keys on Redis.

Data size adds up the storage each engine reports for the changed objects: tables with their indexes on the relational engines (Oracle counts table, index and LOB segments), storage on MongoDB, the primary store on Elasticsearch, estimates on Cassandra and memory on Redis. Neo4j keeps no size per label, so its Data size shows a dash. Two engines need a privilege to read sizes: CockroachDB needs admin or VIEWACTIVITY, and Oracle needs SELECT_CATALOG_ROLE for tables owned by another user. Without it the radius is marked partial and says so.

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

With an AI provider configured, 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. It follows the AI settings: it is refused while an administrator has AI agents switched off or the rate limit is reached, tables an administrator excluded from AI are not named (nor their indexes, triggers and trigger functions), and each summary is recorded in the AI run history.

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 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. Observed consumers can be forgotten from the same panel.

Each engine is read from its own view of what is running, and a consumer is named by its application name where the engine reports one, otherwise by its user:

• PostgreSQL, TimescaleDB and CockroachDB, pg_stat_activity, named by application_name.
• MySQL, performance_schema.threads, named by the program_name connection attribute. MariaDB, information_schema.PROCESSLIST, named by user (it lists other users' sessions only with the PROCESS privilege).
• SQL Server, sys.dm_exec_requests with the request's text, named by program_name (needs VIEW SERVER STATE).
• Oracle, V$SESSION with V$SQL, named by MODULE or PROGRAM (needs read access to those views, for example SELECT_CATALOG_ROLE).
• MongoDB, currentOp for the connection's database, named by appName.
• Neo4j, SHOW TRANSACTIONS, with the labels in each running query, named by the transaction's app metadata or its user.
• Elasticsearch, running search and write tasks, with their indices, named by the X-Opaque-Id header clients send.
• Redis, the commands clients send during a one-second MONITOR window, with their key patterns, named by client name (CLIENT SETNAME) or ACL user; MONITOR slows the server while it runs.
• SQLite and Cassandra cannot be sampled, and the panel says why: SQLite has no server sessions, and Cassandra does not report which client runs a query.

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.