Running PostgreSQL in containers and on Kubernetes is now common, but databases are stateful, which makes them fundamentally different from the stateless apps containers were first designed for. A web server can be killed and replaced freely; a database cannot lose its data directory or be casually rescheduled. Containerising PostgreSQL safely means respecting that statefulness at every layer.
In plain Docker, the essentials are persisting the data directory in a volume so it survives container restarts, configuring via environment variables, and sizing resources. On Kubernetes, PostgreSQL belongs in a StatefulSet with PersistentVolumeClaims — not a Deployment — so each instance gets stable storage and identity. Getting this wrong risks the worst outcome of all: silent data loss.
For production, the strong recommendation is to use a PostgreSQL operator rather than hand-rolling manifests. Operators like CloudNativePG, the Zalando operator, and Crunchy's encode the hard-won knowledge of replication, failover, backups, and upgrades into automation. This lesson covers the container fundamentals, the Kubernetes specifics, and why operators are the right path for stateful PostgreSQL.
Analogy🏏Cricket
🏏 Think of it like cricket: Just as a selection decision can depend on a derived benchmark — 'pick batters whose average exceeds the squad's average', which itself must first be computed — a subquery computes an inner result that the outer query then uses. The insight is that some questions are inherently two-stage: you must establish the benchmark before you can judge against it, and composing queries is how SQL expresses that dependency. Watch the selector actually do it: first he tallies every batter's runs and computes the squad average — that inner computation stands alone, needing nothing from the final decision — and only then does he walk the list judging each player against the number he just derived. That independence is what makes it an uncorrelated subquery: the database can compute the benchmark once, keep it, and reuse it for every row, exactly as the selector does not recompute the squad average per player. The composition also comes in shapes: a benchmark producing one number slots in where a value goes (a scalar subquery in WHERE), while a computed shortlist of qualifying players is itself a table the outer query can select from — a subquery in FROM. Two-stage question, two nested queries, dependency flowing inward-out.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.