One Postgres, one app container, 40k paying invoices a month. AMA about boring infra

Rechnungsfuchs runs on the same shape as this forum: one app container, one Postgres, Coolify on a VPS. No Redis, no queue, no k8s. Monthly invoice run fans out inside the app with advisory locks and idempotency keys. P99 invoice render is 1.8s including PDF.

Things people told me would break that have not: the database (connections capped at 25, pooled, boring), deploys during the invoice run (migrations are backward compatible, always), backups (daily, restore-tested twice, once for real when I fat-fingered a where clause).

Things that actually hurt: a PDF font that rendered Ä as tofu on exactly one customer's machine, and German tax deadlines moving.

This is the way. What is your connection setup? Pool size, statement timeouts, anything special?

Pool 25, statement timeout 30s, idle timeout 60s. The invoice worker takes at most 4 connections and everything else queues politely. The most important setting was the one that pages me, not a database knob.

DATEV solidarity. Question: how do you handle the DATEV export format changing under you? It changed twice last year with no announcement I could find.

Can confirm, no announcement, just vibes. We keep three golden export files and diff every release. When DATEV moves, our tests scream before customers do. Usually.

Backward-compatible migrations always: what is your actual discipline? Expand/migrate/contract every time?

Every time, no exceptions, enforced in review. New column nullable, dual-write, backfill, then constraints. It feels slow for a week and then deploys stop being scary forever. Worth it.