I have a case where two types of Kubernetes applications are using the same database schema. Before they are started, the following happens:

• multiple writers run alembic current in loop waiting for migrations to be applied
• single reader runs alembic upgrade head before it starts

This "locking" mechanism causes problems due to how alembic current is implemented. It's description says:

Display the current revision for a database.

However besides displaying the revision it also tries to create an empty alembic_version table, which may cause race conditions when multiple alembic current commands are being run in parallel:

[...]
sqlalchemy.exc.IntegrityError: (psycopg2.errors.UniqueViolation) duplicate key value violates unique constraint "pg_type_typname_nsp_index"
DETAIL:  Key (typname, typnamespace)=(alembic_version, 2200) already exists.

In fact, it does not make sense to create anything since the output after creation looks like this (the same amount of information could be provided without creating anything):

$ alembic current
INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.

It would be nice if alembic current would implement an early exit if alembic_version table does not exist.