In development you get a database that behaves: single user, small data, matching schema, no interference. You check stock, create an order, record payment, decrement inventory, and serve the confirmation. All your queries run fast, locks never block, and replicas stay in sync. Reality in production looks different. The same tables and connections now serve web requests, background jobs, reports, admin scripts, migrations and more. One heavy report can flush the cache a checkout relies on, a long-running migration can hold locks that stall updates, and an aggressive retry loop can drain all available connections. When a query slows, your application’s worker threads sit idle inside transactions, holding locks and connections—soon the pool fills up and new requests time out. Those timeouts aren’t just “slow database” warnings—they’re real user-facing failures. A delayed inventory update might still be processing when the client gives up and retries, consuming another connection and deepening the backlog. Meanwhile, the first transaction could eventually commit, resulting in duplicate orders or inconsistent stock counts. Treating a slow SQL call as harmless until it outright fails misses the fact that every millisecond waiting also ties up memory, locks and threads, making cascading timeouts inevitable. Metrics like connection‐pool wait time and lock‐wait duration become as critical as error rates, because they directly affect user experience. Concurrency and scale unmask hidden assumptions in that simple checkout code. Two parallel “check stock” calls can both see available inventory and each decrement it, overselling the product. A write committed after a client timeout may live on without the application ever knowing. Replica lag can feed stale data back into reads, leading to decisions based on last night’s state. And when you roll out a schema change, mixing old and new code paths can trigger subtle conflicts or deadlocks. In short, databases in production are shared, multitasking systems under real-world pressures. You need to test your queries and transactions under load, observe lock and replication behavior, and build compensating logic for timeouts, retries, and migrations.