Learn to self-host Postgres on a VPS-style microVM with full root SSH, no shared kernel, and costs under $10/month. Skip the $50 managed DB bill.
A small managed PostgreSQL instance runs $15 to $50 a month, and it still caps your connections at 20 to 50 on the starter tier. When you self-host Postgres VPS style on your own machine, that same $5 to $10 buys you the whole database, your app, and zero artificial limits on max_connections. That gap is why so many developers decide to self-host Postgres VPS setups instead of paying for managed tiers.
The catch: most self-hosting guides drop you into a two-hour rabbit hole of pg_hba.conf edits, firewall rules, and SSH hardening, and one wrong move leaves your data open to the entire internet. This guide shows you how to do it the right way, on infrastructure that stays private by design.
Key takeaways:
pg_hba.conf) and automated backups.Managed services like AWS RDS, Supabase Cloud, and Neon are genuinely convenient. You click a button and you have a database. But you pay for that convenience in three ways that add up fast.
First, price. As Server Compass documents, a small managed instance costs $15 to $50/month, while a single cheap VPS can host both PostgreSQL and your entire application stack. One developer on DEV Community described staring at a $500/month managed DB bill before moving 50+ apps to Docker on $5 VPS boxes for under $10/month each.
Second, control. Managed tiers cap connections, restrict extensions, and hide the config knobs. Self-managed Postgres lets you tune shared_buffers, max_connections, and install any extension your workload needs.
Third, data sovereignty. Your data lives on your server, in your region, with no surprise data-processing agreements.
For a SaaS with a few hundred to a few thousand users, a dedicated Postgres self-hosted setup is almost always cheaper and faster than a managed tier. A popular thread on Hacker News titled "Go ahead, self-host Postgres" drew 683 points and 396 comments. The honest counterpoint: you shift the responsibility for uptime onto yourself. If you want someone else to be paged at 3 AM, managed still wins.
A self-hosted Postgres VPS is simply PostgreSQL that you install and manage yourself on a virtual private server, rather than renting a database-as-a-service. You get root, you own the config files, and you handle backups and updates.
A microVM takes that same idea and puts it inside a lightweight virtual machine with its own Linux kernel. Firecracker, the technology behind this, boots a fresh VM in under one second while keeping true hardware-level isolation, not the shared-kernel model that regular containers use.
Here is the practical difference. A Docker container on a shared host uses the host's kernel, so a kernel-level exploit can potentially reach neighboring workloads. An isolated database VM runs its own kernel, so your Postgres process lives in its own sealed environment. You still get container-like speed, but with VM-grade boundaries around your data.
(Image: side-by-side diagram of a shared-kernel container versus an isolated microVM running Postgres, alt: 'isolated database VM versus shared kernel container for Postgres')
For a database, that isolation matters. Your Postgres instance holds your most sensitive data, and keeping it in a private, single-tenant kernel is a meaningfully smaller attack surface.
The actual work breaks into five moves. None of them take long once you know the order.
Start small. A box with 1 to 2 GB RAM handles thousands of users on a modest SaaS. On Krova Cloud, the entry Cube gives you 1 vCPU, 2 GB RAM, and 20 GB disk for $5/month, and the popular tier bumps you to 2 vCPU and 4 GB RAM for $10/month.
SSH in and install via your package manager (apt install postgresql on Debian/Ubuntu). Many teams instead run it via Docker, which the DEV Community guide calls the cleanest path to a reproducible setup under $10/month. Package installs are simpler for a single database; Docker is nicer if you want pgAdmin or pgBouncer alongside it.
This is the step people rush and regret. Edit pg_hba.conf to control who can connect and how they authenticate. Then configure your firewall (ufw on Ubuntu) to only allow trusted IPs to reach port 5432. Never expose Postgres to 0.0.0.0 with password-only auth.
A cron job running pg_dump on a schedule is the minimum. On Hacker News, one operator described using Barman to restore into separate hourly and daily database instances, so a fresh, verified backup always exists. Untested backups are not backups, so restore them on a schedule.
If you expect 200+ concurrent connections, put pgBouncer in transaction mode in front of Postgres. A Supabase self-hosting thread shows exactly this: PostgreSQL 15 with pgBouncer handling 200+ connections without exhausting Postgres connection slots on a 4 vCPU / 16 GB VPS.
Most people get the security order wrong. They install Postgres, get it working, and then think about firewalls. By that point the database has been reachable on a public IP for hours.
Here is what trips teams up most:
pg_dump takes ten minutes to set up and saves your business.max_connections tuning. Self-managed Postgres lets you raise it, but each connection costs RAM, so size accordingly.The honest trade-off: you own uptime and patching. As one Reddit builder in r/webdev put it, for a modest SaaS with whitelisted IPs and cron backups, that responsibility is very manageable. For a Fortune 500 system with strict SLAs, managed is the safer call.
A plain VPS gives you a machine. An isolated microVM gives you a machine with a smaller attack surface and cleaner economics.
On Krova Cloud, every Cube is a Firecracker microVM with its own kernel, so your Postgres never shares a kernel with another tenant. There is no public IP by default, which means your database is private by architecture, and you open access only through IP-allowlistable TCP port forwarding.
You also keep full root SSH access with no software restrictions, so you can run Postgres root SSH sessions, install any extension, and tune any config exactly like you would on a bare VPS.
The pricing lands where self-hosting is supposed to. An 8 GB RAM equivalent runs $20/month on Krova versus $44 on Lightsail, $48 on DigitalOcean, $40 on Vultr, and $48 on Linode, up to 69% cheaper than the major providers. Per-minute billing means a powered-off Cube stops charging you instantly.
If your goal is a private, isolated Postgres you fully own without babysitting shared-kernel security, a microVM is the sweet spot between a raw VPS and an expensive managed tier.
You can run PostgreSQL alongside your app for under $10/month on a small VPS or microVM. That compares to $15 to $50/month for a starter managed instance, and far more at scale. Entry microVM plans start around $5/month for 1 vCPU and 2 GB RAM.
Yes, if you do three things: restrict access with pg_hba.conf and an IP allowlist, keep the database off a public IP, and run tested automated backups. Running it in an isolated database VM with its own kernel further reduces your attack surface compared to a shared-kernel container.
No. You can install Postgres directly with your package manager for a single database. Docker helps when you want reproducible setups or extra services like pgAdmin and pgBouncer running alongside, and many practitioners prefer it for that reason.
Use pgBouncer in transaction mode in front of Postgres. Real-world setups handle 200+ concurrent connections this way without exhausting Postgres connection slots, something managed starter tiers often cap at 20 to 50.
Engineering deep-dives and product updates. No spam, unsubscribe anytime.
Learn how isolated cloud app hosting lets you run multiple apps on one account without noisy neighbors or data leaks. Practical setup, trade-offs, and next steps.
Self-hosted vs managed cloud: see the hidden costs, real TCO math, and when DIY hosting quietly burns more money than a managed plan ever would.
Learn how to run AI coding agents isolated environment setups that block host access, contain blast radius, and cut costs. A practical 2026 guide for builders.
