I built a tool to solve my own schema change problem

Community Showcase
1

Hey everyone,

A couple weeks ago I posted about schema changes breaking questions. Got some great advice about using views as an abstraction layer and enforcing queries against dbt models only.

That's the right long-term solution, but we still have legacy reports against raw tables and people still create quick queries against production. So I built a tool to at least catch breakages before they hit production:

Usage

metabase-impact \
  --metabase-url http://localhost:3000 \
  --api-key "mb_xxx" \
  --drop-column orders.user_id

It scans all your native SQL questions and tells you which ones reference the column/table you're about to drop. Run it before your migration, fix the affected questions, then deploy.

Features

  • Handles table aliases (SELECT o.user_id FROM orders o)
  • Supports multiple columns/tables at once
  • Works with any native SQL questions

Not a replacement for good architecture, but a safety net for the messy reality.

Install

pip install git+https://github.com/yukipeters/metabase-impact.git

GitHub: GitHub - yukipeters/metabase-impact: Find which Metabase questions will break when you change your database schema

Would love feedback - especially if you hit edge cases it doesn't handle.