Ohne Migrations ändern Sie das Schema manuell in der Produktion. Mit Migrations haben Sie eine versionierte, wiederholbare, reversible Änderungshistorie.

Alembic (Python/SQLAlchemy)¶

Initialisierung¶

alembic init migrations

Migration generieren¶

alembic revision –autogenerate -m “add users table”

Anwenden¶

alembic upgrade head alembic downgrade -1 # Rollback

Migrationsbeispiel¶

def upgrade(): op.create_table(‘users’, sa.Column(‘id’, sa.Integer, primary_key=True), sa.Column(‘email’, sa.String(255), unique=True, nullable=False), sa.Column(‘name’, sa.String(100)), sa.Column(‘created_at’, sa.DateTime, server_default=sa.func.now()), ) op.create_index(‘idx_users_email’, ‘users’, [‘email’]) def downgrade(): op.drop_table(‘users’)

Best Practices¶

• Migrations in der Versionskontrolle
• Idempotent (sicher mehrfach ausführbar)
• Abwärtskompatibel (Deploy vor Migration)
• Test auf Kopie der Produktionsdaten
• Spalten nie direkt löschen — deprecated → remove

Wichtigste Erkenntnis¶

Migrations = versioniertes Schema. Alembic für Python, Flyway für Java, Prisma Migrate für TypeScript.