Why should you care?

PostgresVerse analytics team runs heavy SELECT on standby so BI queries do not steal I/O from checkout primary.

See it live — copy this example

Run in pgAdmin or psql.

-- On standby server
SHOW hot_standby;
SELECT pg_is_in_recovery();

SELECT count(*) FROM orders
WHERE created_at >= current_date;

What happened?

• pg_is_in_recovery() true confirms standby.
• hot_standby on allows SELECT while WAL replays.
• Long queries can conflict with replay — max_standby_streaming_delay applies.

Practice next

1. Connect to standby not primary.
2. Verify pg_is_in_recovery true.
3. Run read-only report query.
4. SET default_transaction_read_only = on on primary session to simulate read-only behavior.
5. Query pg_stat_database_conflicts on standby.

Remember

Physical replica + hot_standby = read scale + DR. Writes always on primary unless promoted. Watch replay conflicts in pg_stat_database conflicts.

PostgresVerse BI offload

Metabase connected to standby; exec dashboards stop slowing OLTP.

Outcome: Primary buffer cache dedicated to checkout queries.