intermediate
The Database Says It Is Fine
Read the evidence before you read the options. The signals are presented the way a dashboard would present them — nothing is labelled with the answer.
The report
The reporting API is slow, and the application team and database team disagree about whose problem it is. The app team points at database spans of nearly a second. The DBA points at a dashboard showing the database at 30% CPU and says there is nothing to fix.
The system
Reporting API — peak hourILLUSTRATIVE
| Signal | Value | What it tells you |
|---|---|---|
| Concurrent requests in flight | 338 average | Around 340 requests are being handled at any moment across all instances. |
| App CPU | 19% | The application instances have plenty of idle capacity. |
| Database span duration (p99) | 910 ms | The instrumented "database call" takes nearly a second at the tail. |
| Connections in use | 20 of 20 per instance | Every configured connection is checked out, on every instance. |
| Pool acquire wait (p99) | 890 ms | Requests spend nearly nine hundred milliseconds obtaining a connection. |
PostgreSQL — same hourILLUSTRATIVE
| Signal | Value | What it tells you |
|---|---|---|
| DB CPU | 30% | The database has substantial spare compute. |
| Query execution time (p99) | 19 ms | Queries complete quickly once they begin executing. |
| Active backends | 120 of max 400 | The server is running well below its configured connection ceiling. |
| Lock waits | 0.2 sessions average | Almost nothing is waiting on a lock. |
Trace excerpt — one request at p99
POST /reports/generate 932 ms ├── auth.verify 4 ms ├── db.query "SELECT ... FROM report_defs" 910 ms │ ├── pool.acquire 889 ms ← no child spans │ └── pg.execute 21 ms └── serialize 12 ms
What is the constraint?