Skip to content

PATTERN Cited by 2 sources

Warn on drop if recently queried

Pattern

At deploy-request review time, before executing any destructive schema change (DROP TABLE, DROP COLUMN, table rename), cross-reference the target object against the platform's recent query log. If the object has been queried inside a recency window, surface a loud advisory warning in the deploy-request UI so the developer can either acknowledge and proceed or back out before any irrevocable operation runs.

Canonical framing (Sam Lambert, PlanetScale CEO, 2022-08-02):

"We've all done it, dropped the wrong table or index and caused queries to dramatically slow or fail. This can lead to entire site outages, as well as cascading failure that impacts other systems… To help prevent this type of outage, PlanetScale warns you if the table to be dropped was recently queried."

(Source: sources/2026-04-21-planetscale-how-planetscale-prevents-mysql-downtime)

Problem

Destructive DDL on a shared production database has the same failure shape across every platform that allows it:

  • Developer inspects the codebase for references to old_table. Finds none.
  • Developer asks the team; nobody remembers using it.
  • DROP TABLE old_table ships.
  • A scheduled report, a partner integration, or a dormant service that runs once a day hits the dropped table → error → pages → outage.

The code-search evidence the developer relied on is lossy by construction:

  • Dynamically-constructed queries don't show up in grep.
  • External callers (BI tools, partner APIs, ad-hoc SQL from analysts) don't appear in the developer's codebase at all.
  • Code search over a single repo misses queries issued by other repos / services.

Meanwhile the platform knows whether the table is live. Every query against it passes through the database server's log. The deploy-request flow can turn that log into a safety net at zero marginal cost to the developer.

Solution

At deploy-request creation (or at the review step), the platform performs a synchronous check against its own workload telemetry:

  1. Parse the migration. Identify which tables / columns / indexes are the target of destructive operations (DROP, TRUNCATE, RENAME — all of which are effectively drops at the mapping level from the caller's perspective).
  2. Query the recent-query log. For each affected object, check: was this object touched by any SELECT / INSERT / UPDATE / DELETE within the recency window (minutes, hours, or days — platform policy)?
  3. Surface the answer on the deploy-request UI. Yes → loud advisory warning ("This table was queried within the last X hours — proceed with caution."). No → no warning.
  4. Let the developer proceed or cancel. The warning is advisory, not blocking — the developer retains the final call, but the platform has made the evidence undeniable.

Why advisory, not blocking

Lambert's canonical framing is "warns you" — a deliberately soft block. The reason: a recently-queried table is not automatically a table-that-must-not-be- dropped. Legitimate reasons the warning fires and the drop should still proceed:

  • The drop is part of a planned migration where the team has already migrated callers to a new table; the remaining queries are residual and will be cut over with the deploy.
  • The queried-by-actor is a dev-only instance (dev box, CI fixtures) and the actor signal would let the developer confirm.
  • The queried-by-actor is the very job being deprecated in this ship — drop table + decommission job are in the same release.

A hard block would force operators around the platform (raw DROP TABLE via mysql CLI, bypassing the deploy request) in these legitimate cases — worse than the warning they'd get inside the flow.

The warning shape also composes cleanly with warn-mode-vs-enforce-mode philosophy: start advisory, accumulate data on false- positive and false-negative rates in practice, and only upgrade to hard-block if the evidence justifies it.

Extension to renames

The same primitive applies to schema renames. PlanetScale does not offer direct RENAME COLUMN DDL; renames are implemented as expand-migrate-contract. At the point the operator requests the rename, the platform surfaces the same warning:

"You cannot do a rename without creating a new column in PlanetScale, but PlanetScale does warn you if a table has been recently queried in a deploy request."

(Source: Dicken)

Renames produce the same "readers still expect the old name" failure mode as drops; the deploy-safety signal catches both.

Composition with schema revert

The pattern is the preventive half of a two-layer safety net. The recovery half is instant schema revert via inverse replication — pre-staged inverse VReplication lets the operator undo a shipped drop inside a 30-minute window without data loss.

Lambert's post canonicalises both layers in the same breath: prevention via the recently-queried warning, recovery via schema revert. Together:

  • Warn at deploy time catches the obvious mistakes pre-flight.
  • Revert after deploy catches the non-obvious mistakes that made it past the warning.

Neither layer is complete alone. Warn-only lets dismissed warnings become outages. Revert-only wastes developer time on outages that were easily avoidable.

Structural requirements

A platform that ships this pattern needs:

  • A per-query log at the platform layer that records object-granularity touch events (which tables / columns each statement reads / writes). Raw SQL logs are the substrate; the interpretation step must run in platform telemetry infra.
  • A schema-diff engine ( schemadiff in the PlanetScale/Vitess case) that can identify which tables / columns a pending migration will touch so the platform knows what to cross-reference against the log.
  • A deploy-request UI that can query the workload telemetry synchronously at review time and render the answer to the developer.

Self-managed databases have the raw query log but don't ship the productised flow.

  • Code-search-only safety check — "I grepped the repo and found no references, so it's safe to drop." Partial; misses dynamic SQL, external callers, other repos. Actively displaces the platform-level check.
  • Hard-block destructive DDL — overcorrects; forces operators around the platform and breaks legitimate release flows where the residual queries are expected.
  • Silent drops — the historical MySQL default. Drops succeed; callers find out when their queries start erroring.

Seen in

Last updated · 347 distilled / 1,201 read