[noise]

That technique used for migrations will fail with a real production app where you want to avoid downtime. The process outlined is:

1. deploy new code to prod

2. run migration on prod via a one-off dyno instance

However, in step 1 you are pushing code that relies on new tables/fields that don't yet exist, causing errors and likely downtime for the app.

To avoid this, you can instead have Alembic generate SQL from the migration and then apply that SQL to the prod DB directly prior to deploying the updated code.

[mjhea0]

Good points. This post is actually meant for the initial setup. You're right, though: - there will be downtown, albeit not much. But down time is down time.

It may be beneficial to update the post to specify the initial setup vs. migrations after the production env is setup. Or we could just add that in the next post.

Thanks!

[noise]

Yeah, it's more of an advanced topic for commercial prod sites, but worth mentioning as trying to do the migration prior to a code push is also not going to work (no migration to be done) and could confuse those new to these tools/libs.

In any case, good job on a well written set of posts.