Phoenix is stateless and supports horizontal scaling; you can run multiple Phoenix containers backed by a single Postgres database. This is a supported and safe approach for handling increased concurrency and workload, as confirmed by the Phoenix team and production guide. However, you should monitor for potential database contention (e.g., deadlocks) under high ingestion load, and tune your batch processor and database settings as needed for your workload. Automated migrations are handled at startup, but using a dedicated database for Phoenix is recommended to avoid conflicts with other applications.
No unique "gotchas" are documented for running multiple instances, but you should ensure proper resource scaling (memory, disk, and database), enable batch processing, and monitor for any database performance issues. If you experience deadlocks or out-of-memory issues, consider tuning batch sizes, queue sizes, and database connection pooling, and avoid running multiple Phoenix pods against the same database without affinity if you see contention issues. Would you like more detail on best practices for scaling or database tuning?
Sources:
- <https://arize-ai.slack.com/archives/C04R3GXC8HK/p1727401604.563959|Phoenix deployment Slack discussion>
- <https://github.com/Arize-ai/phoenix/issues/8879|Phoenix deadlock troubleshooting>
- <https://github.com/Arize-ai/phoenix/issues/9461|Phoenix out-of-memory troubleshooting>
