---
title: "finally fixed: run postgresql on kubernetes without pvb & keep your sanity"
author: "pilput"
canonical: "https://pilput.net/pilput/finally-fixed-run-postgresql-on-kubernetes-without-pvb-keep-your-sanity"
published: "2025-08-10T06:28:30.75138Z"
updated: "2025-08-11T02:23:20.263465Z"
description: "introduction: why everyone panics about postgresql on k8s search for “postgresql on kubernetes” and you’ll see the same gloomy props: hundreds of yaml lines, p..."
---
# finally fixed: run postgresql on kubernetes without pvb & keep your sanity

## introduction: why everyone panics about postgresql on k8s

search for “postgresql on kubernetes” and you’ll see the same gloomy props: hundreds of yaml lines, **persistentvolumeclaims (pvcs)** piling up, and horror stories of data loss. as a **devops full-stack coder**, you want time for **coding** and **seo**, not to babysit volumes. good news: **you can drop pvc/hostpath entirely for many workloads**, keep your sanity, and still run a rock-solid postgresql cluster.

## what to expect from this guide

- a brief **locker-room tour** of when state _must_ live in k8s volumes

- the **volume-less** (pvc-less) pattern that relies on managed services and init containers

- copy-paste-ready yaml and commands _for beginners_

- tips to tune performance, monitor, and backup without losing your weekend to **devops** fire drills

## stage 1: plan your data philosophy

### rule of thumb

use pvc when:

- you can’t tolerate multi-minute latency (cold start of managed pg)

- you must stay **self-hosted** at the edge (air-gapped environments)

skip pvc when:

- you’re allowed to ride **managed postgresql** (cloud sql, rds, alloydb, aurora)

- your staging / development environments accept an occasional _3-5 min spin-up_

**
never** put production customer data on a container’s ephemeral storage—unless your managed host’s sla says it’s their data, not yours.

## stage 2: pick your cloud sql or serverless shape

below table assumes google cloud sql, but the concept maps 1-to-1 in aws rds or azure db.

      workload
      machine type
      cloud sql tier
      cost (usd / month)

      dev / test
      1 vcpu, 1–2 gb ram
      db-f1-micro
      $7-$10

      small saas
      2 vcpu, 4 gb ram
      db-g1-small
      $25-$30

      medium prod
      4 vcpu, 16 gb ram
      db-standard-4
      $100-$130

**tip:** turn on automatic storage increases (_continuous disk-resize_) only if your clients obsess about rois; otherwise use alerts.

## stage 3: let kubernetes find the database through secrets & config

```
apiversion: v1
kind: secret
metadata:
  name: pg-credentials
type: opaque
stringdata:
  postgres_user: "your_app"
  postgres_password: "super-secure-pw"
  postgres_db: "app_db"
  postgres_host: "10.123.45.67"   # cloud sql private ip
  postgres_port: "5432"
```

if you prefer environment variables, mount the secret instead of hard-coding.

```
apiversion: apps/v1
kind: deployment
metadata:
  name: web-api
spec:
  template:
    spec:
      containers:
      - name: app
        image: mycompany/backend:latest
        envfrom:
        - secretref:
            name: pg-credentials
        ports:
        - containerport: 8080
```

**notice:** zero pvc mounted—nothing to expand or back up on the cluster itself.

## stage 4: tame migrations on first pod spin-up

skipping pvc means _initcontainer_ runs migrations fast.

```
apiversion: batch/v1
kind: job
metadata:
  name: db-migrate
spec:
  template:
    spec:
      restartpolicy: onfailure
      containers:
      - name: migrate
        image: mycompany/backend:latest
        command: ["npx", "prisma", "migrate", "deploy"]
        envfrom:
        - secretref:
            name: pg-credentials
```

hook the job inside your github actions or jenkins pipeline so your ci/cd flow triggers migrations automatically—classic **devops**.

      scenario
      command

      connect from local
      `gcloud sql connect app-db --user=your_app --database=app_db`

      get credentials into shell
      `kubectl get secret/pg-credentials -o jsonpath='{.data.postgres_password}' | base64 -d`

      list running jobs
      `kubectl get jobs --field-selector=metadata.name=db-migrate`

## common hurdles & quick fixes

- **hurdle:** “i thought once cloud name changed, all drivers times-out.”**
      fix:** store hostname in k8s secret and reload pods via `kubectl rollout restart deployment/web-api`.

- **hurdle:** slow cold boot scares qa during nightly integration tests.**
      fix:** enable cloud sql _serverless v2_ (scale-to-zero kept off) or keep a small idle instance ($2/day guardrail).

- **hurdle:** “we need read-replicas regionally.”**
      fix:** one-click replica tier in cloud console; add reader endpoints to your `postgres_host_reader` variable—no pvc, no kubelets mutated.

## tl;dr cheat sheet

- provision managed postgresql, **skip pvc**.

- store connection string in a k8s secret; mount via _envfrom_.

- run migrations inside **k8s job** so no local volume folders.

- backup and monitor outside the cluster—cheaper, cleaner, simpler docs for **coding**.

with this setup, postgresql becomes a world-class kitchen sink that doesn't leak into your cluster’s storage plumbing. happy **coding**, even happier **seo** headlines: “finally fixed: run postgresql on kubernetes without pvc & keep your sanity.”