The middle tier for Postgres: own kernel, no public IP, and you own the backups

A developer who used to tell everyone not to self-host Postgres has written up why he now runs it on a Firecracker microVM, and by his own account the deciding factor was isolation rather than cost ^[1][15]. It matters because it names a tier most stacks skip: a box with its own kernel and no public IP by default, at roughly VPS money, for single-node databases that were being billed at managed-service rates for replication features nobody switched on ^[2][5][c13c].

The technical claim is narrow and worth keeping narrow. A microVM boots its own kernel and its own userspace and is isolated by hardware virtualization like any real VM; what changed is start time, with Firecracker, AWS's open-source microVM technology, booting in under a second ^[3][4]. That is close enough to container ergonomics that the shared-kernel compromise stops being free. The author's framing of the three options is blunt: container means shared kernel and a soft boundary, microVM means its own kernel and a real VM boundary, managed means someone else's problem on shared infrastructure at a higher price ^[16].

The mechanics in the post are unremarkable, which is the point. He provisions a 2 vCPU, 4 GB, 80 GB Ubuntu 24.04 instance from a CLI, SSHes in, and installs Postgres from apt under systemd ^[6][8]. Postgres is bound to localhost plus the private interface, and pg_hba admits the app user from 10.0.0.0/24 over scram-sha-256 ^[9]. The application, in another instance, connects on the private IP at port 5432 ^[10]. Administrative SSH is exposed through an IP-allowlisted port mapping to a single /32 ^[11]. He presents the absence of VPCs and security groups as part of the appeal ^[7]; read that carefully, because it means the network boundary is whatever the platform's default of no public IP amounts to, and the post asserts that default without describing what enforces it ^[5].

On price, this is one practitioner's approximation and he says so. He puts managed Postgres at that size at roughly 50 to 200 dollars a month with backups, replication and monitoring included, a public-IP VPS at 20 to 50 with a shared kernel and public attack surface, and the microVM at about 10 with per-minute billing [c13a][c13b][c13c]. Taken at face value that is a factor of five to twenty against the managed option ^[17], or roughly 480 to 2,280 dollars a year on a single database ^[18]. Real, but not the kind of number that decides an architecture on its own.

What actually moves is the backup job. The post is explicit that a managed service gives you backups and a microVM does not, and the replacement offered is a daily cron pg_dump piped through gzip and pushed to object storage ^[12]. A daily logical dump puts the worst-case recovery point at close to 24 hours of lost writes ^[19], which is a different product from what the 50-to-200-dollar line item was selling [c13a]. The author's own boundary is consistent with that: fine for side projects, small SaaS, learning and workloads where you want full control; not for multi-region, not for mission-critical systems without an on-call DBA, not for teams that need automatic failover ^[14].

Two things to watch. First, whether anyone in this pattern rehearses a restore rather than just confirming the dump ran. Second, whether the roughly 10-dollar figure and the per-minute billing survive contact with sustained disk-heavy workloads [c13c], since the post prices the box and not the I/O behaviour of a database on it.