Why should you care?

Swiggy peak lunch hour runs thousands of concurrent order inserts — PostgreSQL handles row-level contention better than table-level locking engines.

See it live — copy this example

Run in pgAdmin or psql.

SELECT count(*) AS active_backends
FROM pg_stat_activity
WHERE datname = 'PostgresVerse' AND state = 'active';

SELECT relname, row_locks
FROM (
  SELECT relation::regclass AS relname, count(*) AS row_locks
  FROM pg_locks
  WHERE mode = 'RowExclusiveLock' AND relation IS NOT NULL
  GROUP BY relation
) s;

What happened?

• pg_stat_activity counts live queries.
• pg_locks aggregates RowExclusiveLock per table — typical during INSERT/UPDATE concurrency.

Practice next

1. Run active_backends during quiet and busy periods.
2. Start long UPDATE in one session; observe locks in pg_locks from another.
3. Run pgbench -c 10 on PostgresVerse if installed.
4. Compare contention updating same row vs different rows in parallel scripts.
5. Set max_connections realistically vs PgBouncer pool size.

Remember

Row-level locks scope contention to touched rows. Monitor pg_stat_activity and pg_locks under load. Pool connections — one process per user does not scale.

PostgresVerse lunch rush

Ops watches active_backends spike to 400; PgBouncer pools 100 real connections.

Outcome: Database stays responsive; app tier scales horizontally.