diff --git a/migrations/env.py b/migrations/env.py
index 0b4049e..7b15020 100644
--- a/migrations/env.py
+++ b/migrations/env.py
@@ -147,6 +147,21 @@ def run_migrations_online():
         with context.begin_transaction():
             context.run_migrations()
 
+        # COMMIT THE RUN. SQLAlchemy 2.0 connections do not autocommit, and on
+        # MySQL alembic reports "non-transactional DDL" so begin_transaction()
+        # above is a no-op - nothing here commits on its own.
+        #
+        # It looked like it worked because MySQL implicitly commits on DDL: each
+        # ALTER/CREATE flushed everything queued before it, including the
+        # PREVIOUS migration's version stamp. The LAST migration of every run
+        # has no DDL after it, so its stamp was rolled back at close. The column
+        # changes survived (already committed by their own DDL) while
+        # alembic_version stayed one revision behind, so `flask db upgrade`
+        # exited 0 having silently re-run the final migration, and re-ran it
+        # again on the next deploy. A migration that is not idempotent would
+        # apply twice.
+        connection.commit()
+
 
 if context.is_offline_mode():
     run_migrations_offline()