Site Reliability Engineer
I run a self-hosted Temporal platform and the PostgreSQL fleet behind it. I like finding the real cause of an incident, fixing it so it stays fixed, and writing it down.
Disposable Ubuntu 24.04 servers in Docker that behave like fresh VPSes — systemd as PID 1, sshd, sudo, cron, and journald with static private IPs — for deploying and testing DevOps/SRE automation over SSH without renting machines.
Multi-tenant SaaS control plane where every tenant lifecycle operation — provision, upgrade, migrate, backup, restore, delete — runs as a durable Temporal workflow with saga compensation and a retryable DLQ.
Active-passive HA lab with nginx, keepalived (VRRP), a Go backend, and a full observability stack (Prometheus, Grafana, Loki, Alertmanager) — single-command Docker Compose deploy with an automated failover test suite.
A self-contained Linux patch governance platform — Aptly mirror/snapshot promotion, a custom-built AWX standalone install orchestrating everything on a schedule, and Grafana dashboards backed by a Postgres governance DB.
Three patterns make a dashboard query cheap — a denormalized table, a materialized view, and a flattened snapshot table — and they look alike until one of them takes the production database down. Measured story: a BI tool with stored-SQL virtual datasets was pushing 961 MB/s of buffer traffic into a shared primary from two open browser tabs. This post is the decision guide (including where each pattern breaks, and a rank-by-measurement rule for choosing) plus the production fix that took dashboards off the primary entirely: a dedicated reporting database, a resource-restricted ETL role, and incremental 15-minute refresh that recomputes only what changed.
PostgreSQL forks a whole OS process per connection, so a dozen eager client pools can push a primary past 500 backends while under 6% of them run a query. This post builds PgBouncer from the wire up — transaction pooling and the per-backend state it breaks, named prepared statements, SCRAM pass-through so no password touches disk, a second HBA because Docker's published ports bypass iptables, and the sizing arithmetic that finally lowered the backend count — with the four things that broke along the way.
Plain VACUUM 'never shrinks the file'. VACUUM FULL shrinks it but is an outage. pg_repack does the same rewrite online for seconds of locking. When each one is the right call, how to measure bloat cheaply (including TOAST, which everyone forgets), the capacity arithmetic so you don't PANIC mid-run — and the two jobs that share VACUUM's name but not its purpose: the anti-wraparound FREEZE that keeps the 32-bit transaction clock from running out, and the ANALYZE statistics pass that keeps the planner honest. All of it grounded in a real incident.
How I built a complete active-passive high-availability load balancer — two nodes running nginx + a Go backend + keepalived/VRRP, with a floating virtual IP, full observability, and an automated test suite that proves failover actually works. The five design decisions that matter, how failure detection is layered, and why your availability claim is worthless without CI to back it up.
Questions about reliability, Temporal or PostgreSQL, or a role you think I'd fit. Write here, or use your own mail.