A feature flag that changes SQL needs a startup schema probe, not just a spelling check

Setup: one image serves two deployments; an env var (MODE=named|anonymous) decides whether queries select an extra column. Anonymous omits the column entirely, so it runs fine against a database that never got the migration. The value was already validated against a closed set, which felt like the mode was guarded.

It was not. Validating the SPELLING of a mode is not validating the mode. The other precondition lived in the database: with MODE=named and no migration, every statement naming the column failed — including the auth lookup, which runs on every authenticated request. Result was UndefinedColumnError: column "x" of relation "users" does not exist on 100% of authenticated routes, while the startup banner printed mode=named as though honoured. The container entrypoint migrated before serving, so this was only reachable via a skip-migrations env var or an externally managed schema — both supported, neither exercised.

Fix: one SELECT 1 FROM information_schema.columns WHERE table_schema=… AND table_name=… AND column_name=… at startup, in the affected mode only, and refuse to boot if absent.

Three things that mattered in the design:

1. Refuse vs downgrade. Refusing wins when the degraded mode DESTROYS data (here: the anonymous path drops the incoming value on purpose, so a silent downgrade means every user who registered during it has nothing to recover). Refusing is also not a worse outage than “every authed route 500s” — it is the same outage, earlier, with the cause in the message.

2. A connection failure is not an answer. If the pool is lazy (min_size=0), the probe is often the FIRST connection ever opened, so an unreachable/starting database must warn and continue, not raise — otherwise you convert “Postgres is still booting” into a crash-loop. Refuse only on the positive finding (we asked, the column is not there). information_schema helps here: it always exists, so the only way the statement can fail is not reaching the server — which is what makes a blanket except Exception: warn correct rather than sloppy.

3. Placement. In FastAPI, put it in lifespan OUTSIDE any try/except that exists to keep a diagnosable container alive, or the handler swallows your refusal and you serve anyway. Test the placement, not just the check: async with app.router.lifespan_context(app) / the lifespan cm should raise.

Also: print one line in every outcome (verified / could-not-verify / refused). A check that is silent when it passes and silent when it could not run is a check an operator cannot use.