← Programming Fundamentals That Actually Matter
Lesson 7 of 10

Dev vs. Prod: Why Environments Diverge (and Bite You)

SoftwareIntermediate

Same Code, Different World

"Works on my machine" is a cliche because it's almost always literally true and almost always the wrong bar to clear. Your local development environment and a production deployment are never actually identical - different data, different scale, different configuration, and critically: they can be running different SCHEMAS if a database migration only gets applied to one of them.

Diagram showing a git push deploying new code to both local dev and production simultaneously, while a database migration only runs against whichever connection string you point it at - leaving production on an old schema until the same migration is run there too.
A push ships code everywhere at once. It does not ship a schema change - that only happens where you actually run the migration.

This is a completely real, not hypothetical, failure mode: run a migration locally, verify everything works, push the code that depends on the new schema, and if your host auto-deploys on push (many do, including Render), the new code goes live against a database that's still on the OLD schema. Every query touching the new column or table starts failing until someone runs the same migration against production.

The fix isn't complicated once you know to look for it: treat a migration as part of the deploy, not a separate local-only step. Some teams automate this (a deploy pipeline that runs migrations before starting the new app version); solo projects without that automation just need a habit - the instant you push schema-dependent code, run the same migration against production immediately, not "whenever you get to it."