Paul
One of the questions I get asked most often by other solo founders building platforms is what database provider I use, and the answer surprises people because it's not what most people recommend. I don't use Supabase, I don't use Neon, I don't use AWS RDS, I don't use Digitalocean Managed Database or any of the other managed database services that have become the default recommendation in the last few years. Instead I run my own database servers across a mix of Hetzner VPS instances, Netcup Root Server instances, and OVH bare metal dedicated servers, with the specific choice depending on the size and traffic profile of the platform that database is serving.
This isn't because I think managed databases are bad, because for a lot of founders they're absolutely the right call, but rather because once you're running more than a couple of platforms the economics and control tradeoffs start tilting hard toward self-hosting for anyone willing to put in the upfront learning. I've been running this setup for some months now across more than ten platforms, and I want to lay out the actual reasoning so other solo founders can decide whether the same approach makes sense for them.
Why managed databases stop making sense at scale
The pitch for managed databases is genuinely compelling on a single project, where you pay a higher monthly fee, you don't have to think about backups or upgrades or replication, and you can focus on building your product instead of running infrastructure. That tradeoff is real and I'm not dismissing it, because the time you save on a single platform is genuinely valuable when you're trying to figure out whether the platform itself is going to work at all.
The math changes once you're running multiple platforms simultaneously, because the per-platform cost of a managed database stacks up fast and you start paying for the same convenience over and over again across projects that don't need it independently. A managed Postgres instance from one of the major providers can easily run $50 to $1,000+ a month for a setup that handles real traffic, which sounds reasonable for one platform but becomes painful when you multiply it by ten and realize you're spending more on databases than you are on everything else combined. That same money buys you significantly more capacity and control if you're running your own.
The other thing that changes at scale is that you start to actually care about the things managed databases hide from you, like which underlying hardware you're on, what the noisy neighbor situation looks like, how upgrades are scheduled, and what happens when the provider has an outage. Early on these abstractions feel like features, but once you've been bitten by them a few times they start to feel like restrictions on your ability to actually run your business. The first time a managed database provider schedules a maintenance window in the middle of your peak traffic and there's nothing you can do about it, you start thinking differently about what "managed" really means.
And there's a more subtle problem that's worth noting, which is that managed databases lock you into a specific provider in ways that are hard to reverse later. The connection strings, the backup formats, the proprietary extensions, the IAM integrations, they all create switching costs that compound the longer you stay. Self-hosted Postgres is Postgres anywhere, where the database I run on Hetzner today could be moved to Netcup or OVH or anywhere else tomorrow with nothing more than a pg_dump and a few hours of work. That portability is genuinely valuable and most founders only realize they want it after they're already stuck.
The three-tier setup I actually use
The setup I've landed on is a three-tier system where I match the database provider to the platform's size and traffic profile rather than running everything on the same infrastructure. The reasoning for splitting across providers is partly cost optimization and partly redundancy, since I don't want all my platforms to go down if a single provider has a bad day, but the bigger reason is that different providers are genuinely better at different things and using each one for what it does best is more efficient than committing to a single vendor across the whole portfolio.
The first tier is Hetzner VPS instances, which I use for my smaller platforms because the price-to-performance ratio is one of the best in the industry and their US network in Ashburn and Hillsboro is fast enough that the platforms feel snappy even though the cost is a fraction of what AWS would charge for equivalent capacity. A database VPS on Hetzner with enough memory to actually run Postgres well costs me roughly $15 to $80 a month, while a comparable managed database from one of the major providers would run several times that for the same capacity. The setup is a separate VPS for the database paired with a separate VPS for the app, so I can scale each tier independently and a runaway query on the database doesn't take down the web server or vice versa. The other thing Hetzner does well is easy rescaling, where you can resize a VPS up or down through the control panel in a few clicks, which matters more than it sounds because you don't always know in advance how much capacity a platform is going to need.
The frustration with Hetzner lately is that their US data centers in Ashburn and Hillsboro have been chronically out of capacity, where you'll go to provision a new VPS and the size you want simply isn't available for purchase, and the workaround is either waiting for inventory to refresh or settling for a different instance size than you actually wanted. That's a real friction point for someone running a portfolio of platforms because new launches don't always wait for Hetzner to add hardware, and it's part of why I've ended up diversifying across providers rather than going all-in on Hetzner the way the cost numbers would otherwise suggest.
The second tier is Netcup Root Server instances, which I use when I need dedicated CPU and RAM resources without paying for full bare metal, and where I want some of my platforms running on completely separate infrastructure as insurance against any single provider having a bad day. Netcup's pricing is actually cheaper than Hetzner's for comparable specs and their hardware leans slightly higher on raw performance per dollar, which makes them the right call for certain workloads where I want dedicated resources but the platform isn't quite big enough to justify bare metal. The tradeoffs with Netcup are real and worth knowing about before you sign up: the control panel is dated in a way that takes getting used to, the rescaling options aren't nearly as flexible as Hetzner's where you can resize with a few clicks, and while Netcup has been reliable for me overall Hetzner has been more reliable in absolute terms. The upside that balances all of that is that Netcup has consistent capacity available, where I've never been told I can't provision the size I want, which is the exact opposite of the Hetzner US situation right now.
The third tier is OVH bare metal dedicated servers, which I use for the bigger platforms where the traffic profile justifies the additional cost and where having actual dedicated hardware rather than virtualized resources makes a meaningful difference. Bare metal at OVH starts around $20 a month for entry-level configurations (eco-dedicated) with much older hardware (around 10-years-old) and goes up from there depending on specs. I typically get their $100+ a month bare metal dedicated servers. It is more expensive compared to VPS pricing until you realize that you're getting an entire physical machine to yourself with no noisy neighbors, no resource contention, and predictable performance under load. For a platform doing serious traffic, the consistency you get from bare metal is worth far more than the cost difference, and the upgrade path from VPS to bare metal is straightforward enough that you can start a platform on cheap VPS and graduate it to bare metal when the traffic justifies the move. The real tradeoff with bare metal is that you lose the snapshot-and-restore safety net that VPS providers give you, where a hardware failure on a VPS means you spin up a new instance in minutes from a recent snapshot and you're back online, while a hardware failure on bare metal means you're waiting on the provider's support team to actually swap or repair the physical machine, which can take hours rather than minutes. The way to mitigate that risk is with proper redundancy at the application layer, where you run a load balancer in front of multiple app servers and pair your main database with read replicas so a single hardware failure doesn't take the whole platform down. You also can have similar setups at different locations for even more redundancy, but all of this is a meaningfully more complex setup than the typical solo founder is running, and it's the reason bare metal really only makes sense once a platform has enough revenue to justify both the hardware cost and the operational complexity that comes with running production right. I am also thinking about getting some dedicated servers at Hivelocity to expand from one bare metal provider, and maybe eventually colocation at a datacenter.
The match between platform and tier is essentially a function of how much the platform earns and how much pain it causes when the database has a bad day. New platforms and lower-traffic platforms run on Hetzner or Netcup VPS, mature platforms with real revenue run on bare metal with redundancy, and the ones in between get promoted as their traffic patterns demand it. This sounds more complicated than it is because each tier uses the same Postgres configuration and the same deployment process, so promoting a platform from VPS to bare metal is mostly a question of running pg_dump on the old server, restoring it on the new server, and updating the connection strings in the application config.
What you actually have to do to run your own database
I want to be honest about the work involved because the recommendation to self-host only makes sense if you're willing to actually do the work, and a lot of the content recommending managed databases skips over how much work self-hosting really is. The truth is somewhere in the middle, where running your own database is harder than using a managed service but not nearly as hard as the managed-database providers want you to think it is.
The core setup is straightforward, where you spin up a server, install Postgres, configure it for your hardware and workload, set up automated backups, and put it behind a private network so it's not exposed to the public internet. The first time you do this it takes a weekend because you're learning, and the second time it takes a few hours because you've written down what you learned, and the tenth time it takes maybe thirty minutes because you've automated most of it. The learning curve is real but it's also short and finite, where you climb it once and then you've climbed it for every future platform.
The maintenance work after the initial setup is genuinely minimal for most workloads, because Postgres is one of the most stable pieces of software and the typical month involves doing essentially nothing to it. The major versions of Postgres release once a year, the minor versions release a few times a year with security patches, and the rolling upgrade process is well documented and rarely surprises you. The mental load is much lower than the managed-database marketing material implies, and most of the horror stories you hear about running your own database are from people who didn't bother to learn what they were doing before deploying to production.
The piece that does require real attention is backups, and this is where solo founders most often cut corners in ways that bite them later. I run Borgbackup (Restic is also a good choice) against all my database servers, pushing encrypted backups to Storage Boxes at various datacenters across North America that's completely separate from the production servers, and I actually test the restore process at least once per platform every few months so I know the backups work rather than just hoping they do. This sounds tedious and it is, but it's also the single most important piece of self-hosting infrastructure, because a database without working backups is a time bomb that's going to take your platform with it when it goes off. Along with the borgbackups, for the VPS instances I usually also have daily snapshots saved for backups and for the bare metal, I have hot standbys ready which are stored on the same private network but not the same machine.
The security setup is the other piece that solo founders need to take seriously, because exposing a Postgres instance to the public internet with default settings is one of the fastest ways to get compromised. Database servers should be on a private network with the web tier as the only thing that can reach them, the postgres user should not be accepting external connections, and you should be using strong randomly-generated passwords or certificate-based authentication for any access that does happen. None of this is hard but all of it is necessary, and the managed-database providers handle it for you by default, which is a real benefit of using them even when the other tradeoffs go the other way.
When managed databases are still the right call
I want to make it clear that self-hosting isn't the right answer for everyone and there are real scenarios where I'd recommend a managed database over the setup I'm running. The most obvious one is if you genuinely have no interest in learning database administration and you'd rather pay a premium to never think about it, because that's a legitimate position and managed databases are designed exactly for that buyer.
The second case is if you're building something where the database workload is unusual in some way, like requiring extremely high availability with automatic failover, or running a workload that doesn't fit comfortably on a single server and needs sharding or distributed setup from day one. The managed services can absorb that complexity in ways that would take serious effort to replicate yourself, and unless you genuinely enjoy that kind of work you should let the managed providers do it for you.
The third case is if you're a single founder on a single platform and you genuinely value the time savings more than the cost. The math I described earlier kicks in at multiple platforms, but if you're on platform one and trying to find product-market fit, paying $50 a month for a managed Postgres so you can focus entirely on the product is probably the right call. The break-even point on self-hosting starts to favor it somewhere around the third or fourth platform, and below that the managed services are often the better trade.
The fourth case is regulatory or compliance scenarios where the managed providers offer certifications and audit trails that you'd have a hard time replicating on your own infrastructure. HIPAA, SOC 2, and similar frameworks are easier to satisfy with a managed provider that's already been audited than with a self-hosted setup where you have to prove the controls yourself.
What I'd recommend
For new solo founders running a single platform, the honest recommendation is to start with a managed database because the time savings are real and the cost is fine when you're only paying for one. The moment you find yourself building a third or fourth platform with a similar database profile, that's when you should seriously consider learning to self-host, because the per-platform cost of managed databases starts to add up faster than you'd expect.
For solo founders already running multiple platforms on managed databases, the migration path is straightforward but should be done carefully. Pick your smallest and least critical platform, set up a self-hosted Postgres on Hetzner or Netcup, dump and restore the data, and run both in parallel for a few weeks to make sure the self-hosted version is behaving correctly under real traffic. Once you've done one migration successfully, the rest get progressively easier because you've already built the muscle and the operational knowledge.
For platforms that grow into real traffic, the path from VPS to bare metal is also worth understanding because it gives you somewhere to graduate to when the VPS tier starts feeling cramped. Bare metal at OVH or Hivelocity are genuinely affordable compared to managed alternatives at the same performance level, and the upgrade is the same dump-and-restore operation you'd do for any database migration.
The bigger point I want to make is that self-hosting your databases is not as scary as it gets made out to be, and the skills you develop doing it transfer to every platform you'll ever build for the rest of your career. Managed databases are a service where you rent the hardware and the expertise as a bundle, while self-hosting is a setup where you rent the hardware separately and develop the expertise yourself, and the second arrangement is what actually compounds for a solo founder over time. The hardware is a commodity that you can move between providers whenever the economics shift, but the operational knowledge of running your own infrastructure is an asset that carries over to every platform you'll ever build, which is the part that pays off across years rather than months. Claude Code helps a lot with the operational learning curve too, where you can spin up a new database server and walk through the configuration with the model rather than having to dig through documentation alone, which makes the whole self-hosting path significantly more accessible than it was even two years ago.
