Quick answer
Database observability should connect user demand to useful committed work and finite resources. For the Spring order service, correlate admission, pool acquisition, active transactions, locks, plans, I/O, storage, logs, and replica state. A single utilization percentage cannot explain correctness or capacity.
Learning objectives
- Build a bounded evidence chain from checkout impact to engine and durable-order state.
- Use PostgreSQL 18 and MySQL 8.4 views without exposing credentials, parameters, personal data, or unbounded labels.
Prerequisites
Understand pools, transactions, locks, query plans, replication, and basic metrics, logs, and traces.
Shared relational contract
Measure arrival, admission, queueing, completion, rejection, and retry separately. Pool wait may reflect slow SQL, blocked transactions, leaked sessions, network interruption, or over-admission. More sessions can reduce throughput by increasing contention. Capacity plans must include maintenance, backup, failover, migration, and recovery work.
Telemetry needs bounded query fingerprints and stable low-cardinality dimensions. Never log passwords, connection strings, authorization tokens, raw customer SQL parameters, or unrestricted statement text.
PostgreSQL 18 boundary
Use PostgreSQL statistics views for sessions, databases, tables, indexes, WAL, replication, vacuum, and progress according to documented reset and sampling semantics. Locks and wait events give current evidence; extensions such as statement aggregation are optional and must be governed separately.
MySQL 8.4 InnoDB boundary
Use Performance Schema, sys views, InnoDB metrics and status, data-lock views, replication status, and error logs according to 8.4 instrumentation settings. Consumers and history tables have retention and overhead boundaries. Do not transpose PostgreSQL wait names onto MySQL instruments.
Production failure scenario
Checkout timeouts rise while CPU remains moderate. Pool acquisition and transaction age are high, with one reporting query holding locks. Bound new admission, preserve safe fingerprints and lock graphs, end the offending work through procedure, then verify useful commits, queue drainage, affected orders, replicas, and sustained headroom.
Common misconceptions
- Low CPU does not prove spare transactional capacity.
- More connections do not always add throughput.
- One sampled trace does not define population impact.
- Green dashboards do not prove durable order correctness.
Decision checklist
Retain the observation window, signal ownership, instrumentation settings, and uncertainty when application and engine evidence disagree; never turn one sample into a production limit.
- Start with user impact and useful completions.
- Correlate pool, transaction, lock, plan, I/O, and replica evidence.
- Bound cardinality, text, retention, and access.
- Reserve maintenance and recovery headroom.
- Verify business outcomes after mitigation.
Related reading
Review sharding, continue to incident troubleshooting, use the course and topic, deepen with production slow-query troubleshooting, and connect to observability for backend systems.
Official sources
- PostgreSQL 18 monitoring, accessed August 19, 2026.
- PostgreSQL 18 lock monitoring, accessed August 19, 2026.
- MySQL 8.4 Performance Schema, accessed August 19, 2026.
- MySQL 8.4 sys schema, accessed August 19, 2026.