Answer.

In a microservices architecture, each service often owns its own database. To manage schema migrations, specialized migration tools (Liquibase, Flyway, Alembic) should be used, and they should be executed through a CI/CD pipeline for automation and predictability of results.

A good practice is to prepare each migration as a migration script with versioning and Idempotency — re-running the same change will not result in an error or inconsistency.

Example migration using Python Alembic:

from alembic import op
import sqlalchemy as sa

def upgrade():
    op.add_column('user', sa.Column('status', sa.String(8)))

def downgrade():
    op.drop_column('user', 'status')

Key features:

• Automation of migrations at the CI/CD level
• Idempotency — the ability to reapply without harming the structure
• Versioning of data schemas and rollbacks

Tricky questions.

Is it permissible to manually change the database schema in production without migrations (manual DDL)?

This is categorically not recommended: you will lose control over the schema state and face difficulties in rollback/tracking changes.

Is it true that in a microservices architecture migrations should be executed centrally for all services?

No, each team/service is responsible for its own schema and its migration pipeline. Centralization contradicts the principles of service independence.

Is rollback of migrations completely safe?

No: it is not always possible to revert changes, especially if the structure or format of data has changed (for example, if a field has been deleted and data is lost). It is better to design migrations with rollback in mind.