Siva M.

Thank you!

Any updates on when this PR might be merged?

Got a curiosity question about this statement in your PR.

Phoenix's migrations are designed to be safe under concurrent execution — if two pods race, one will fail with a transient error, retry, find the database already at head, and exit cleanly.

Is this because Phoenix takes a Postgres application level lock?

Thank you Roger!

Roger this what I was kinda thinking about. https://github.com/Arize-ai/phoenix/pull/12072

Roger, What is happening is that we are running Phoenix in K8s and we have large PostgreSQL database. While doing a 12.X -> 13.X Phoenix rolling upgrade the new Pods were stuck in a CrashLoopBackoff because liveliness probe fails. This was due migrations taking a long time. We would prefer not to run manual commands in PostgreSQL production database as outlined in the v13 migration doc. I would ideally like to run just the migrations in K8s initContainers before starting up the main container running the server. It would nice if there was a similar command to phoenix.server.main serve for migrations. With the help of Claude, I was testing out some of the migrations commands with Docker. I was able to get this to work. The async create_engine_and_run_migrations that runs on startup basically just calls create_engine.

docker run --rm --network phoenix_default \                                                             
  -e PHOENIX_SQL_DATABASE_URL=postgresql://postgres:postgres@db:5432/postgres \
  arizephoenix/phoenix \
  -c "from phoenix.db.engines import create_engine; import os; create_engine(os.environ['PHOENIX_SQL_DATABASE_URL'], migrate=True); print('Migrations complete.')"

Migrations complete.

RunLLM What about with the production Docker image distribution?