Thanks for raising this — with ~284 deployments, the Deployments page shouldn’t feel “overly” slow, but there are a few known reasons it can, especially in Prefect 3.x. Why this can happen - The UI/API loads rich metadata for each deployment: schedules, next run time, last run info, work pool/queue, tags, etc. This can trigger multiple queries per deployment (joins/existence checks against flow runs, schedules, work pools). At a few hundred deployments, those queries and the response payload can get heavy. - If you’re self-hosting on SQLite, list/filter queries across hundreds of rows with related data are noticeably slower than on Postgres. - The UI may fetch a large page of deployments on a regular refresh interval, compounding load when the API responses are slow. - General DB latency/resource pressure will surface here first; we’ve seen server loops slow down when the DB is sluggish. See: Prefect Server timeouts due to slow DB comms Quick checks to isolate the bottleneck 1) Compare UI vs API/CLI: - If CLI is fast but UI is slow, it’s likely payload size/refresh/pagination in the UI.

prefect deployments ls --by-created

2) Check the API with pagination (self-hosted):

curl -s -X POST "$PREFECT_API_URL/api/deployments/paginate" \
  -H "Content-Type: application/json" \
  -d '{"limit": 50}'

If this is quick, loading fewer at a time helps. 3) Confirm your setup: - Prefect version:

prefect version

- Are you on Prefect Cloud or self-hosted? If self-hosted, which DB (SQLite vs Postgres)? Practical mitigations - If you’re on SQLite, move to Postgres for production-scale servers; ensure migrations are up-to-date:

prefect server database upgrade

- Reduce the number of deployments shown at once (use filters or pagination if available in your UI) to lower payload size and query work. - Archive/delete unused or duplicate deployments to shrink the result set and related joins. - Keep current with Prefect 3.x; we regularly ship UI/API performance improvements. Latest release notes: Prefect releases - On self-hosted Postgres, check DB health: - Enable slow query logging - Verify autovacuum is running - Ensure the server has enough CPU/RAM and there’s no proxy-induced latency - If you have deployments with many schedules/triggers per deployment, reducing those can help (it reduces related lookups the UI/API performs). If you can share a bit more, I can tailor guidance: - Prefect version and Cloud vs self-hosted - Backing DB (SQLite vs Postgres and version) - Whether

prefect deployments ls

is also slow - Roughly how many schedules/triggers per deployment If you’re on Prefect Cloud, I can take a closer look if you share your workspace name and a timestamp of when the slowness occurs.