Why You Need Migrations, Not create_all
The risk of editing live schemas by hand.
Why You Need Migrations, Not create_all is a free Flask Academy lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Flask Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Schemas Always Change
Real apps evolve, so your tables must change too. You will add columns, rename fields, and drop old ones as features grow. 🔄
create_all Only Builds Once
Remember the limit you met earlier: create_all only makes missing tables. It never touches a table that already exists.
db.create_all()The Tempting Bad Fix
One tempting fix is drop then recreate. It works in a demo, but it deletes every row, which is unthinkable in production.
db.drop_all()
db.create_all()Editing by Hand Is Risky
Running raw ALTER TABLE by hand on a live database is fragile. One typo or missed step can corrupt data with no easy undo.
What a Migration Is
A migration is a small script that moves your schema from one version to the next in safe, repeatable steps.
Versioned and Ordered
Each migration has a version id and points to the one before it. Together they form an ordered history of every schema change.
Forward and Backward
A migration defines two paths: upgrade applies the change, and downgrade reverses it if something goes wrong.
def upgrade():
...
def downgrade():
...Flask-Migrate Wraps Alembic
Flask-Migrate connects your app to Alembic, the tool that detects schema changes and writes the migration scripts for you.
It Tracks the Current Version
Migrations record the current schema version inside a table called alembic_version, so the tool always knows where you are.
Safe Across Every Environment
The same migration scripts run on your laptop, in CI, and in production, so every environment ends up with an identical schema.
When to Switch
Use create_all only for the very first prototype. The moment your model starts changing, move to migrations for good.
Quick Check
Your table exists and you just added a column. Why not rely on create_all?
Recap
You saw why create_all cannot evolve a schema and how migrations bring safe, versioned, reversible changes. 🎉
Frequently asked questions
Is the “Why You Need Migrations, Not create_all” lesson free?
Yes — the full text of “Why You Need Migrations, Not create_all” is free to read here on the web, and the Flask Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Flask Academy course, upgrade to CoddyKit PRO.
What will I learn in “Why You Need Migrations, Not create_all”?
The risk of editing live schemas by hand. You practise Flask Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Flask Academy?
No prior experience is required. Flask Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Why You Need Migrations, Not create_all” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Flask Academy lesson?
Yes. Every Flask Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Why You Need Migrations, Not create_all
- Init and Autogenerate a Migration
- Apply and Roll Back with upgrade
- Review and Edit Generated Scripts