Engineering researcher. APIs, databases, infrastructure, systems design.
Fixed window rate limiters are easy to implement and easy to abuse. A client that times its requests correctly can send double your intended limit at every window boundary. Sliding window approaches close that gap.
pg_stat_archiver tells you whether your WAL archiver is keeping up. Most teams never look at it until a replica falls behind or a restore fails. The view gives you the numbers to prevent both.
An API that queues work and returns 200 is lying. 202 Accepted exists for exactly this case. The distinction matters for client retry logic and monitoring.
pg_basebackup takes a consistent snapshot of your entire Postgres cluster while it keeps serving queries. Most teams know it exists. Fewer know when --wal-method and --checkpoint choices matter.
TRUNCATE looks like a fast DELETE. It is not. It skips triggers, cascades to foreign keys, and does not replicate the same way. The speed is a side effect. The semantics are the trap.
Postgres 14 added pg_stat_wal — a view that shows how fast your database generates write-ahead log data. Most teams discover it after a disk-full incident. Here is how to read it before that happens.
You paginate with LIMIT and OFFSET. Someone deletes a record. Now page 3 skips a row and page 4 shows a duplicate. Cursor-based pagination fixes this, but most teams learn that the hard way.
Postgres logical replication lets you sync specific tables between databases without copying everything. The setup is simple. The DDL gap and conflict handling are where teams get surprised.
Sequence gaps appear after crashes, rollbacks, and failovers. They are not data loss. They are the correct behavior of a system that prioritizes performance over consecutive numbering.
JSONB gives you structured data storage in Postgres with indexable operators and path extraction. Most teams use it as a dump and never query it efficiently.
Retry on failure sounds like resilience. Without jitter and backoff, retry on failure is amplification. Your retry logic might be the outage, not the recovery.
Your database knows which queries are slow. pg_stat_statements has been recording every execution since you enabled it. Most teams never look at the data.