Topic Hub
SQL and data correctness problems are rarely only about one query. Slow plans, missing indexes, replica lag, isolation levels, locks, schema changes, and worker concurrency all affect whether the system stays fast and correct under production traffic.
This hub collects CodeNotes articles for the database problems that tend to cross boundaries: diagnosing slow queries, understanding why scaling did not help, choosing concurrency controls, and rolling out data changes without breaking live requests.
Start from the symptom or decision in front of you, then use the article that matches that database boundary.
A production SQL query is slow and the source of pressure is unclear.
How to Find and Fix Slow SQL Queries in Production
An index exists, but the query still scans, sorts, or stays slow.
Why Database Indexes Didn’t Fix Your Slow Query
Read replicas moved traffic, but the primary database stayed hot.
Why Read Replicas Didn't Reduce Database Load
Concurrent transactions see data in surprising ways.
SQL Isolation Levels Explained
Several requests can update the same row or business object.
Optimistic vs Pessimistic Locking in SQL
A schema change must roll out without breaking live traffic.
Safe Database Migrations in Production
Workers need to claim database-backed jobs without blocking each other.
PostgreSQL Job Queues with SKIP LOCKED
These articles are grouped by the pressure they help explain: query cost, scaling behavior, transaction visibility, locking, and production data change.
Start here when the database is slow, replicas do not move load, or indexes do not behave the way the plan expected.
A production-oriented workflow for finding slow SQL, reading signals, and choosing the right fix.
A practical production workflow for finding slow SQL queries, reading plans, picking the right fix, and avoiding fake optimizations.
Why an index can exist and still not solve the query because of selectivity, planner choices, or workload shape.
Adding an index often seems like the obvious SQL fix, but query latency can remain unchanged when the planner and data shape disagree.
How read-coupled writes, replica lag, fallback behavior, and query cost keep pressure on the primary.
Why read replicas often fail to reduce primary database load when reads are coupled to writes, replica lag triggers fallback behavior, and query cost is misunderstood.
Use these guides when the risk is not only latency, but whether the data stays correct under live traffic.
Understand how isolation levels shape what transactions can see while concurrent writes are happening.
A practical guide to SQL isolation levels, including Read Committed, Repeatable Read, and Serializable, with backend examples and production trade-offs.
Compare conflict handling strategies when several requests may update the same data.
A practical guide to optimistic and pessimistic locking in SQL, including version columns, SELECT FOR UPDATE, lost updates, and when to use each approach in production.
Roll out schema changes with expand-and-contract, resumable backfills, constraint staging, and rollback planning.
A practical rollout plan for safe database migrations using expand-and-contract, phased constraints, resumable backfills, rollback planning, and production monitoring.
Use PostgreSQL row locking carefully when queue workers need concurrent job claiming.
How to build a PostgreSQL job queue with FOR UPDATE SKIP LOCKED, including safe claiming, retries, stuck-job recovery, and the production trade-offs that matter.
Query tuning explains where work is spent. Indexes explain whether the database can avoid unnecessary work. Replicas explain which reads can move away from the primary. Isolation and locking explain what concurrent transactions can safely do. Migrations explain how to change the data shape while old and new code overlap.
The common thread is that database behavior is part of application correctness. A query that is fast in isolation, a lock that is safe in a test, or a migration that works locally can still fail when production traffic, concurrency, and data size change the shape of the problem.