9 ms·

Go ahead, self-host Postgres

• arichard123 11mo ago
  I've been self hosting it for 20 years. Best technical decision I ever made. Rock solid
  • newsoftheday 11mo ago
    I've been selfhosting it for at least 10 years, it and mysql, mysql longer. No issues selfhosting either. I have backups and I know they work.
    • moxplod 11mo ago
      What server company are you guys using with high reliability? Looking for server in US-East right now.
• ipsento606 11mo ago
  > If your database goes down at 3 AM, you need to fix it. Of all the places I've worked that had the attitude "If this goes down at 3AM, we need to fix it immediately", there was only one where that was actually justifiable from a business perspective. I'm worked at plenty of places that had this attitude despite the fact that overnight traffic was minimal and nothing bad actually happened if a few clients had to wait until business hours for a fix. I wonder if some of the preference for big-name cloud infrastructure comes from the fact that during an outage, employees can just say "AWS (or whatever) is having an outage, there's nothing we can do" vs. being expected to actually fix it From this perspective, the ability to fix problems more quickly when self hosting could be considered an antifeature from the perspective of the employee getting woken up at 3am
  • jonahx 11mo ago
    This is also the basis for most SaaS purchases by large corporations. The old "Nobody gets fired for choosing IBM."
  • zbentley 11mo ago
    Really? That might be an anecdote sampled from unusually small businesses, then. Between myself and most peers I’ve ever talked to about availability, I heard an overwhelming majority of folks describe systems that really did need to be up 24/7 with high availability, and thus needed fast 24/7 incident response. That includes big and small businesses, SaaS and non-SaaS, high scale (5M+rps) to tiny scale (100s-10krps), and all sorts of different markets and user bases. Even at the companies that were not staffed or providing a user service over night, overnight outages were immediately noticed because on average, more than one external integration/backfill/migration job was running at any time. Sure, “overnight on call” at small places like that was more “reports are hardcoded to email Bob if they hit an exception, and integration customers either know Bob’s phone number or how to ask their operations contact to call Bob”, but those are still environments where off-hours uptime and fast resolution of incidents was expected. Between me, my colleagues, and friends/peers whose stories I know, that’s an N of high dozens to low hundreds. What am I missing?
    • runako 11mo ago
      > What am I missing? IME the need for 24x7 for B2B apps is largely driven by global customer scope. If you have customers in North American and Asia, now you need 24x7 (and x365 because of little holiday overlap). That being said, there are a number of B2B apps/industries where global scope is not a thing. For example, many providers who operate in the $4.9 trillion US healthcare market do not have any international users. Similarly the $1.5 trillion (revenue) US real estate market. There are states where one could operate where healthcare spending is over $100B annually. Banks. Securities markets. Lots of things do not have 24x7 business requirements.
      • zbentley 11mo ago
        I’ve worked for banks, multiple large and small US healthcare-related companies, and businesses that didn’t use their software when they were closed for the night. All of those places needed their backend systems to be up 24/7. The banks ran reports and cleared funds with nightly batches—hundreds of jobs a night for even small banking networks. The healthcare companies needed to receive claims and process patient updates (e.g. your provider’s EMR is updated if you die or have an emergency visit with another provider you authorized for records sharing—and no, this is not handled by SaaS EMRs in many cases) over night so that their systems were up to date when they next opened for business. The “regular” businesses closed for the night generated reports and frequently had IT staff doing migrations, or senior staff working on something at midnight due the next day (when the head of marketing is burning the midnight oil on that presentation, you don’t want to be the person explaining that she can’t do it because the file server hosting the assets is down all the time after hours). And again, that’s the norm I’ve heard described from nearly everyone in software/IT that I know: most businesses expect (and are willing to pay for or at least insist on) 24/7 uptime for their computer systems. That seems true across the board: for big/small/open/closed-off-hours/international/single-timezone businesses alike.
  • laz 11mo ago
    The worst SEV calls are the one where you twiddle your thumbs waiting for a support rep to drop a crumb of information about the provider outage. You wake up. It's not your fault. You're helpless to solve it.
    • OccamsMirror 11mo ago
      Not when that provider is AWS and the outage is hitting news websites. You share the link to AWS being down and go back to sleep.
      • laz 11mo ago
        No. You sit on the call and wait to restore your service to your users. There’s bullshit toil in disabling scale in as the outage gets longer. Eventually, AWS has a VP of something dial in to your call to apologize. They’re unprepared and offer no new information. The get handed to a side call for executive bullshit. AWS comes back. Your support rep only vaguely knows what’s going on. Your system serves some errors but digs out. Then you go to sleep.
      • sixdonuts 10mo ago
        News is one thing, if the app/service down impacts revenue, safety or security you won't be getting any sleep AWS or not.
• odie5533 11mo ago
  Recommends hosting postgres yourself. Doesn't recommend a distribution stack. If you try this at a startup to save $50 a month, you will never recoup the time you wasted setting it up. We pay dedicated managed services for these things so we can make products on top of them.
  • ijustlovemath 11mo ago
    There's not much to recommend; just use the Postgres from your distribution's LTS repo. I like Debian for its rock solid stability.
    • odie5533 11mo ago
      Patroni, Pigsty, Crunchy, CloudNativePG, Zalando, ...
    • notaseojh 11mo ago
      "just use postgres from your distro" is *wildly* underselling the amount of work that it takes to go from apt install postgres to having a production ready setup (backups, replica, pooling, etc). Granted, if it's a tiny database just pg-dumping might be enough, but for many that isn't going to be enough.
      • dvtkrlbs 11mo ago
        I don't think any of these would take more than a week to setup. Assuming you create a nice runbook with every step it would not be horrible to maintain as well. Barman for backups and unless you need multi-master you can use the builtin publication and subscription. Though with scale things can complicated really fast but most of the time you won't that much traffic to have something complicated.
        • deleted 11mo ago
          [deleted]
      • true_religion 10mo ago
• ijustlovemath 11mo ago
  And if you want a supabase-like functionality, I'm a huge fan of PostgREST (which is actually how supabase works/worked under the hood). Make a view for your application and boom, you have a GET only REST API. Add a plpgsql function, and now you can POST. It uses JWT for auth, but usually I have application on the same VLAN as DB so it's not as rife for abuse.
  • satvikpendem 11mo ago
    You can self host Supabase too.
    • SamDc73 10mo ago
      Last time I checked, it was a pain in the ass to self-host it
      • satvikpendem 10mo ago
        I assume by their own design and also because there are a lot of moving pieces they packaged up together.
• irusensei 11mo ago
  And then there is the urge to Postgres everything. I was disappointed alloy doesn't support timescaledb as a metrics endpoint. Considering switching to telegraf just because I can store the metrics on Postgres.
  • ErroneousBosh 11mo ago
    I've always just Postgressed everything. I used MySQL a bit in the PHP3 days, but eventually moved onto Postgres. SQLite when prototyping, Postgres for production. If you need to power a lawnmower and all you have is a 500bhp Scania V8, you may as well just do it.
    • WillDaSilva 11mo ago
      It's pretty easy these days to spin up a local Postgres container. Might as well use it for prototyping too, and save yourself the hassle of switching later.
      • tcdent 11mo ago
        It might seem minor, but the little things add up. Make your dev environment mirror prod from the start will save you a bunch of headaches. Then, when you're ready to deploy, there is nothing to change. Even better, stage to a production-like environment early, and then deploy day can be as simple as a DNS record change.
        • OccamsMirror 11mo ago
          Thanks to LetsEncrypt DNS-01, you can absolutely spin up a production-like environment with SSL and everything. It's definitely worth doing.
    • solarengineer 11mo ago
      Have you given thought to why you prototype with SQLite? I have switched to using postgres even for prototyping once I prepared some shell scripts for various setup. With hibernate (java) or knex (Javascript/NodeJS) and with unit tests (Test Driven Development approach) for code, I feel I have reduced the friction of using postgres from the beginning.
• ZeroConcerns 11mo ago
  So, yeah, I guess there's much confusion about what a 'managed database' actually is? Because for me, the table stakes are: -Backups: the provider will push a full generic disaster-recovery backup of my database to an off-provider location at least daily, without the need for a maintenance window -Optimization: index maintenance and storage optimization are performed automatically and transparently -Multi-datacenter failover: my database will remain available even if part(s) of my provider are down, with a minimal data loss window (like, 30 seconds, 5 minutes, 15 minutes, depending on SLA and thus plan expenditure) -Point-in-time backups are performed at an SLA-defined granularity and with a similar retention window, allowing me to access snapshots via a custom DSN, not affecting production access or performance in any way -Slow-query analysis: notifying me of relevant performance bottlenecks before they bring down production -Storage analysis: my plan allows for #GB of fast storage, #TB of slow storage: let me know when I'm forecast to run out of either in the next 3 billing cycles or so Because, well, if anyone provides all of that for a monthly fee, the whole "self-hosting" argument goes out of the window quickly, right? And I say that as someone who absolutely adores self-hosting...
  • dangoodmanUT 11mo ago
    There should be no data loss window with a hosted database
    • xboxnolifes 11mo ago
      Why is that?
    • andersmurphy 10mo ago
      Feom what I remember if AWS loses your data they are basically give you some credits and that's it.
    • jeremyjh 10mo ago
      That requires synchronous replication, which reduces availability and performance.
  • thedougd 11mo ago
• notaseojh 11mo ago
  Another thread where I can't determine whether the "it's easy" suggestions are from people who are clueless or expert.
  • Nextgrid 11mo ago
    Ironically you need a bit of both. You need to be expert enough to make it work, but not "too" expert to be stuck in your ways and/or influenced by all the fear-mongering. An expert will give you thousands of theoretical reasons why self-hosting the DB is a bad idea. An "expert" will host it, enjoy the cost savings and deal with the once-a-year occurrence of the theoretical risk (if it ever occurs).
• isuckatcoding 11mo ago
  Take a look at https://github.com/vitabaks/autobase https://github.com/vitabaks/autobase In case you want to self host but also have something that takes care of all that extra work for you
  • runako 11mo ago
    Thank you, this looks awesome.
  • satvikpendem 11mo ago
    I wonder how well this plays with other self hosted open source PaaS, is it just a Docker container we can run I assume?
  • yakkomajuri 10mo ago
    Just skimmed the readme. What's the connection pooling situation here? Or is it out of scope?
• heipei 11mo ago
  I still don't get how folks can hype Postgres with every second post on HN, yet there is no simple batteries-included way to run a HA Postgres cluster with automatic failover like you can do with MongoDB. I'm genuinely curious how people deal with this in production when they're self-hosting.
  • christophilus 11mo ago
    I’ve been tempted by MariaDB for this reason. I’d love to hear from anyone who has run both.
    • paulryanrogers 11mo ago
      IMO Maria has fallen behind MySQL. I wouldn't chose it for anything my income depends on. (I do use Maria at home for legacy reasons, and have used MySQL and Pg professionally for years.)
      • danaris 11mo ago
        > IMO Maria has fallen behind MySQL. I wouldn't chose it for anything my income depends on. Can you give any details on that? I switched to MariaDB back in the day for my personal projects because (so far as I could tell) it was being updated more regularly, and it was more fully open source. (I don't recall offhand at this point whether MySQL switched to a fully paid model, or just less-open.)
        • chuckadams 11mo ago
          One area where Maria lags significantly is JSON support. In MariaDB, JSON is just an alias for LONGTEXT plus validation: https://mariadb.com/docs/server/reference/data-types/string-data-types/json https://mariadb.com/docs/server/reference/data-types/string-...
        • paulryanrogers 11mo ago
          IME MariaDB doesn't recover or run as reliably as modern versions of MySQL, at least with InnoDB.
• nhumrich 11mo ago
  What do you postgres self hosters use for performance analysis? Both GCP-SQL and RDS have their performance analysis pieces of the hosted DB and it's incredible. Probably my favorite reason for using them.
  • cuu508 11mo ago
    I use pgdash and netdata for monitoring and alerting, and plain psql for analyzing specific queries.
  • sa46 11mo ago
    I’ve been very happy with Pganalyze.
• donatj 11mo ago
  The author brings up the point, but I have always found surprising how much more expensive managed databases are than a comparable VPS. I would expect a little bit more as a cost of the convenience, but in my experience it's generally multiple times the expense. It's wild. This has kept me away from managed databases in all but my largest projects.
  • orev 11mo ago
    Once they convince you that you can’t do it yourself, you end up relying on them, but didn’t develop the skills you would need to migrate to another provider when they start raising prices. And they keep raising prices because by then you have no choice.
    • zbentley 11mo ago
      There is plenty of provider markup, to be sure. But it is also very much not a given that the hosted version of a database is running software/configs that are equivalent to what you could do yourself. Many hosted databases are extremely different behind the scenes when it comes to durability, monitoring, failover, storage provisioning, compute provisioning, and more. Just because it acts like a connection hanging off a postmaster service running on a server doesn’t mean that’s what your “psql” is connected to on RDS Aurora (or many of the other cloud-Postgres offerings).
      • aranelsurion 11mo ago
        > Just because it acts like a connection hanging off If anything that’s a feature for ease of use and compatibility.
    • citizenpaul 11mo ago
      I have not tested this in real life yet but it seems like all the argument about vendor lock in can be solved, if you bite the bullet and learn basic Kubernetes administration. Kubernetes is FOSS and there are countless Kubernetes as a service providers. I know there are other issues with Kubernetes but at least its transferable knowledge.
• dewey 11mo ago
  I recently was also doing some research into what projects exist that come close to a “managed Postgres on Digital Ocean” experience, sadly there’s some building blocks but nothing that really makes it a complete no-brainer. https://blog.notmyhostna.me/posts/what-i-wish-existed-for-self-hosted-databases https://blog.notmyhostna.me/posts/what-i-wish-existed-for-se...
• molf 11mo ago
  > I'd argue self-hosting is the right choice for basically everyone, with the few exceptions at both ends of the extreme: > If you're just starting out in software & want to get something working quickly with vibe coding, it's easier to treat Postgres as just another remote API that you can call from your single deployed app > If you're a really big company and are reaching the scale where you need trained database engineers to just work on your stack, you might get economies of scale by just outsourcing that work to a cloud company that has guaranteed talent in that area. The second full freight salaries come into play, outsourcing looks a bit cheaper. This is funny. I'd argue the exact opposite. I would self host only: * if I were on a tight budget and trading an hour or two of my time for a cost saving of a hundred dollars or so is a good deal; or * at a company that has reached the scale where employing engineers to manage self-hosted databases is more cost effective than outsourcing. I have nothing against self-hosting PostgreSQL. Do whatever you prefer. But to me outsourcing this to cloud providers seems entirely reasonable for small and medium-sized businesses. According to the author's article, self hosting costs you between 30 and 120 minutes per month (after setup, and if you already know what to do). It's easy to do the math...
  • convolvatron 11mo ago
    its not. I've been in a few shops that use RDS because they think their time is better spend doing other things. except now they are stuck trying to maintain and debug Postgres without having the same visibility and agency that they would if they hosted it themselves. situation isn't at all clear.
    • molf 11mo ago
      Interesting. Is this an issue with RDS? I use Google Cloud SQL for PostgreSQL and it's been rock solid. No issues; troubleshooting works fine; all extensions we need already installed; can adjust settings where needed.
      • convolvatron 11mo ago
        its more of a general condition - its not that RDS is somehow really faulty, its just that when things do go wrong, its not really anybody's job to introspect the system because RDS is taking care of it for us. in the limit I dont think we should need DBAs, but as long as we need to manage indices by hand, think more than 10 seconds about the hot queries, manage replication, tune the vacuumer, track updates, and all the other rot - then actually installing PG on a node of your choice is really the smallest of problems you face.
• alexpadula 11mo ago
  Everyone and their mother wants to host Postgres for you!
• bradley13 11mo ago
  Huh? Maybe I missed something, but...why should self-hosting a database server be hard or scary? Sure, you are then responsible for security backups, etc...but that's not really different in the cloud - if anything, the cloud makes it more complicated.
  • xboxnolifes 11mo ago
    I'd say a managed dB, at minimum, should be handling upgrades and backups for you. If it doesn't, thats not a managed db, thats a self-service db. You're paying a premium to do the work yourself.
  • empthought 11mo ago
    Self-hosting a database server is not particularly hard or scary for an engineer. Hiring and replacing engineers who can and want to manage database servers can be hard or scary for employers.
    • Nextgrid 11mo ago
      > Hiring and replacing engineers who can and want to manage database servers can be hard or scary for employers. I heard there's this magical thing called "money" that is claimed to help with this problem. You offer even half of the AWS markup to your employees and suddenly they like managing database servers. Magic I tell you!
  • m4ck_ 11mo ago
    Well for the clickops folks who've built careers on the idea that 'systems administration is dead'... I imagine having to open a shell and install some stuff or modify a configuration file is quite scary.
• zbentley 11mo ago
  For a fascinating counterpoint (gist: cloud hosted Postgres on RDS aurora is not anything like the system you would host yourself, and other cloud deployments of databases should also not be done like our field is used to doing it when self-hosting) see this other front page article and discussion: https://news.ycombinator.com/item?id=46334990 https://news.ycombinator.com/item?id=46334990
  • LunaSea 11mo ago
    Aurora is a closed-source fork of PostgreSQL. So it is indeed not possible to self-host it. However a self-hosted PostgreSQL on a bare metal server with NVMe SSDs will much faster than what RDS is capable of. Especially at the same price points.
    • zbentley 11mo ago
      Yep! I was mostly replying to TFA’s claim that AWS RDS is > Standard Postgres compiled with some AWS-specific monitoring hooks … and other operational tools deployed alongside it. That’s not always true: RDS classic may be those things, but RDS Aurora/Serverless is anything but. As to whether > self-hosted PostgreSQL on a bare metal server with NVMe SSDs will much faster than what RDS is capable of That’s often but not always true. Plenty of workloads will perform better on RDS (read auto scaling is huge in Serverless: you can have new read replica nodes auto-launch in response to e.g. a wave of concurrent, massive reporting queries; many queries can benefit from RDS’s additions to/modifications of the pg buffer cache system that work with the underlying storage)—and that’s even with the VM tax and the networked-storage tax! Of course, it’ll cost more in real money whether or not it performs better, further complicating the cost/benefit analysis here. Also, pedantically, you can run RDS on bare metal with local NVMEs.
      • LunaSea 11mo ago
        > Also, pedantically, you can run RDS on bare metal with local NVMEs. Only if you like your data to evaporate when the server stops. I'm relatively sure that the processing power and memory you can buy on OVH / Hetzner / co. is larger and cheaper even if you take into account peaks in your usage patterns.
• adenta 11mo ago
  I wish this article would have went more in-depth on how they're setting up backups. The great thing about sequel light is lightstream makes backup and restore something you don't really have to think about
  • cosmosgenius 11mo ago
    for postgres specifically pgbackrest works well. Using in a home doing backups to r2 and local s3.
  • olavgg 11mo ago
    ZFS snapshot, send, receive, clone, spin up another postgresql server on the backup server, take full backup on that clone once per week
• petterroea 11mo ago
  I have ran (read: helped with infrastructure) a small production service using PSQL for 6 years, with up to hundreds of users per day. PSQL has been the problem exactly once, and it was because we ran out of disk space. Proper monitoring (duh) and a little VACUUM would have solved it. Later I ran a v2 of that service on k8s. The architecture also changed a lot, hosting many smaller servers sharing the same psql server(Not really microservice-related, think more "collective of smaller services ran by different people"). I have hit some issues relating to maxing out the max connections, but that's about it. This is something I do on my free time so SLA isn't an issue, meaning I've had the ability to learn the ropes of running PSQL without many bad consequences. I'm really happy I have had this opportunity. My conclusion is that running PSQL is totally fine if you just set up proper monitoring. If you are an engineer that works with infrastructure, even just because nobody else can/wants to, hosting PSQL is probably fine for you. Just RTFM.
  • reilly3000 10mo ago
    But it’s 1500 pages long!
    • petterroea 10mo ago
      Good point. I sure didn't read it myself :D I generally read the parts I think I need, based on what I read elsewhere like Stackoverflow and blog posts. Usually the real docs are better than some random person's SO comment. I feel that's sufficient?
  • kunley 10mo ago
    Psql (lowercase) is the name of the textual sql client for PostgreSQL. For a general abbreviation we rather use "Pg".
    • petterroea 10mo ago
      Good catch, thx
• cromulent 11mo ago
  Without disagreeing: Sometimes it is nice to simplify the conversation with non-tech management. Oh, you want HA / DR / etc? We click a button and you get it (multi-AZ). Clicking the button doubles your DB costs from x to y. Please choose. Then you have one less repeating conversation and someone to blame.
• zsoltkacsandi 11mo ago
  I've operated both self-hosted and managed database clusters with complex topologies and mission-critical data at well-known tech companies. Managed database services mostly automate a subset of routine operational work, things like backups, some configuration management, and software upgrades. But they don't remove the need for real database operations. You still have to validate restores, build and rehearse a disaster recovery plan, design and review schemas, review and optimize queries, tune indexes, and fine-tune configuration, among other essentials. In one incident, AWS support couldn't determine what was wrong with an RDS cluster and advised us to "try restarting it". Bottom line: even with managed databases, you still need people on the team who are strong in DBOps. You need standard operating procedures and automation, built by your team. Without that expertise, you're taking on serious risk, including potentially catastrophic failure modes.
  • Nextgrid 11mo ago
    I've had an RDS instance run out of disk space and then get stuck in "modifying" for 24 hours (until an AWS operator manually SSH'd in I guess). We had to restore from the latest snapshot and manually rebuild the missing data from logs/other artifacts in the meantime to restore service. I would've very much preferred being able to SSH in myself and fix it on the spot. Ironically the only reason it ran out of space in the first place is that the AWS markup on that is so huge we were operating with little margin for error; none of that would happen with a bare-metal host where I can rent 1TB of NVME for a mere 20 bucks a month. As far as I know we never got any kind of compensation for this, so RDS ended up being a net negative for this company, tens of thousands spent over a few years for laptop-grade performance and it couldn't even do its promised job the only time it was needed.
• satvikpendem 11mo ago
  Better yet, self host Postgres on your own open source PaaS with Coolify, Dokploy, or Canine, and then you can also self host all your apps on your VPS too. I use Dokploy but I'm looking into Canine, and I know many have used Coolify with great success.
• gynecologist 11mo ago
  I didnt even know there were companies that would host postgres for you. I self host it for my personal projects with 0 users and it works just fine, so I don't know why anyone would do it any differently.
  • satvikpendem 11mo ago
    I can't tell if this is satire or not with the first sentence and the "0 users" parts of your comment, but I know several solo devs with millions of users who self host their database and apps as well.
    • da02 10mo ago
      What hosting providers do they use/recommend?
      • satvikpendem 10mo ago
        I believe they use Hetzner although there are some comparison sites too: https://serverlist.dev https://serverlist.dev
• phendrenad2 11mo ago
  Self-hosting is one of those things that makes sense when you can control all of the variables. For example, can you stop the developers from using obscure features of the db, that suddenly become deprecated, causing you to need to do a manual rolling back while they fix the code? A one-button UI to do that might be very handy. Can you stop your IT department from breaking the VPN, preventing you from logging into the db box at exactly the wrong time? Having it all in a UI that routes around IT's fat fingers might be helpful.
• kachapopopow 11mo ago
  since this is on the front page (again?) I guess I'll chime in: learn kubernetes - it's worth it. It did take me 3 attempts at it to finally wrap my head around it I really suggest trying out many different things and see what works for you. And I really recommend starting with *default* k3s, do not look at any alternatives to cni, csi, networked storage - treat your first cluster as something that can spontaniously fail and don't bother keeping it clean learn as much as you can. Once you have that, you can use great open-source k8s native controllers which take care of vast majority of requirements when it comes to self-hosting and save more time in the long run than it took to set up and learn these things. Honerable mentions: k9s, lens(I do not suggest using it in the long-term, but UI is really good as a starting point), rancher webui. PostgreSQL specifically: https://github.com/cloudnative-pg/cloudnative-pg https://github.com/cloudnative-pg/cloudnative-pg If you really want networked storage: https://github.com/longhorn/longhorn https://github.com/longhorn/longhorn I do not recommend ceph unless you are okay with not using shared filesystems as they have a bunch of gotchas or if you want S3 without having to install a dedicated deployment for it.
  • satvikpendem 11mo ago
    Check out canine.sh, it's to Kubernetes what Coolify or Dokploy is to Docker, if you're familiar with self hosted open source PaaS.
    • kachapopopow 11mo ago
      I just push to git where there is a git action to automatically synchronize deployments
    • chuckadams 11mo ago
      And on a similar naming note yet totally unrelated, check out k9s, which is a TUI for Kubernetes cluster admin. All kinds of nifty features built-in, and highly customizable.
      • satvikpendem 11mo ago
        If we're talking about CLIs, check out Kamal, the build system that 37signals / Basecamp / DHH developed, specifically to move off the cloud. I think it uses Kubernetes but not positive, it might just be Docker.
• markstos 11mo ago
  I hosted PostgreSQL professionally for over a decade. Overall, a good experience. Very stable service and when performance issues did periodically arise, I like that we had full access to all details to understand the root cause and tune details. Nobody was employeed as a full-time DBA. We had plenty of other things going on in addition to running PostgreSQL.
• jhatemyjob 11mo ago
  I wish this post went into the actual how! He glossed over the details. There is a link to his repo, which is a start I suppose: https://github.com/piercefreeman/autopg https://github.com/piercefreeman/autopg A blog post that went into the details would be awesome. I know Postgres has some docs for this (https://www.postgresql.org/docs/current/backup.html https://www.postgresql.org/docs/current/backup.html), but it's too theoretical. I want to see a one-stop-shop with everything you'd reasonably need to know to self host: like monitoring uptime, backups, stuff like that.
• lbrito 11mo ago
  I'm probably just an idiot, but I ran unmanaged postgres on Fly.io, which is basically self hosting on a vm, and it wasn't fun. I did this for just under two years, and I've lost count of how many times one or more of the nodes went down and I had to manually deregister it from the cluster with repmgr, clone a new vm and promote a healthy node to primary. I ended up writing an internal wiki page with the steps. I never got it: if one of the purposes of clusters is having higher availability, why did repmgr not handle zombie primaries? Again, I'm probably just an idiot out of my depth with this. And I probably didn't need a cluster anyway, although with the nodes failing like they did, I didn't feel comfortable moving to a single node setup as well. I eventually switched to managed postgres, and it's amazing being able to file a sev1 for someone else to handle when things go down, instead of the responsibility being on me.
  • indigodaddy 11mo ago
    Assuming you are using fly's managed postgres now?
    • lbrito 10mo ago
      Yep
• mittermayr 11mo ago
  Self-hosting is more a question of responsibility I'd say. I am running a couple of SaaS products and self-host at much better performance at a fraction of the cost of running this on AWS. It's amazing and it works perfectly fine. For client projects, however, I always try and sell them on paying the AWS fees, simply because it shifts the responsibility of the hardware being "up" to someone else. It does not inherently solve the downtime problem, but it allows me to say, "we'll have to wait until they've sorted this out, Ikea and Disney are down, too." Doesn't always work like that and isn't always a tried-and-true excuse, but generally lets me sleep much better at night. With limited budgets, however, it's hard to accept the cost of RDS (and we're talking with at least one staging environment) when comparing it to a very tight 3-node Galera cluster running on Hetzner at barely a couple of bucks a month. Or Cloudflare, titan at the front, being down again today and the past two days (intermittently) after also being down a few weeks ago and earlier this year as well. Also had SQS queues time out several times this week, they picked up again shortly, but it's not like those things ...never happen on managed environments. They happen quite a bit.
  • bossyTeacher 11mo ago
    > Self-hosting is more a question of responsibility I'd say. I am running a couple of SaaS products and self-host at much better performance at a fraction of the cost of running this on AWS It is. You need to answer the question: what are the consecuences of your service being down for lets say 4 hours or some security patch isn't properly applied or you have not followed the best practices in terms of security? Many people are technically unable, lack the time or the resources to be able to confidently address that question, hence paying for someone else to do it. Your time is money though. You are saving money but giving up time. Like everything, it is always cheaper to do it (it being cooking at home, cleaning your home, fixing your own car, etc) yourself (if you don't include the cost of your own time doing the service you normally pay someone else for).
    • jbverschoor 11mo ago
      Yea I agree.. better outsource product development, management, and everything else too by that narrative
• sapphirebreeze 11mo ago
  [dead]
• alexfromapex 11mo ago
  Just don't try to build it from source haha. Compiling Postgres 18 with the PostGIS extension has been such a PITA because the topology component won't configure to not use the system /usr/bin/postgres and has given me a lot of grief. Finally got it fixed I think though.
  • olavgg 11mo ago
    I actually always build PostgreSQL from source as I want 32kb block size as default. It makes ZFS compression more awesome.
• wreath 11mo ago
  > Take AWS RDS. Under the hood, it's: Standard Postgres compiled with some AWS-specific monitoring hooks A custom backup system using EBS snapshots Automated configuration management via Chef/Puppet/Ansible Load balancers and connection pooling (PgBouncer) Monitoring integration with CloudWatch Automated failover scripting I didn't know RDS had PgBouncer under the hood, is this really accurate? The problem i find with RDS (and most other managed Postgres) is that they limit your options for how you want to design your database architecture. For instance, if write consistency is important to you want to support synchronous replication, there is no way to do this in RDS without either Aurora or having the readers in another AZ. The other issue is that you only have access to logical replication, because you don't have access to your WAL archive, so it makes moving off RDS much more difficult.
  • mystifyingpoi 11mo ago
    > I didn't know RDS had PgBouncer under the hood I don't think it does. AWS has this feature under RDS Proxy, but it's an extra service and comes with extra cost (and a bit cumbersome to use in my opinion, it should have been designed as a checkbox, not an entire separate thing to maintain). Although, it technically has "load balancer", in form of a DNS entry that resolves to a random reader replica, if I recall correctly.
• jurschreuder 11mo ago
  I moved from AWS RDS to ScaleWay RDS, had the same effect on cost
  • heyalexej 11mo ago
    Without stating actual numbers if not comfortable, what was the % savings one over the other? Happy with performance? Looking at potential of doing the same move.
• ergonaught 11mo ago
  > Self-hosting a database sounds terrifying. Is this actually the "common" view (in this context)? I've got decades with databases so I cannot even begin to fathom where such an attitude would develop, but, is it? Boggling.
  • Nextgrid 11mo ago
    Over a decade of cloud provider propaganda achieves that. We appear to have lost the basic skill of operating a *nix machine, so anything even remotely close to that now sounds terrifying. You mean you need to SSH into the box? Horrifying!
  • gnusi 10mo ago
    Can't agree more.
• FragrantRiver 11mo ago
  People really love jumping through hoops to avoid spending five dollars.
• TheRealPomax 11mo ago
  > When self-hosting makes sense: 1. If you're just starting out in software & want to get something working quickly [...] This is when you use SQLite, not Postgres. Easy enough to turn into Postgres later, nothing to set up. It already works. And backups are literally just "it's a file, incremental backup by your daily backups already covers this".
• slroger 11mo ago
  Great read. I moved my video sharing app from GCP to self hosted on a beefy home server+ cloudflare for object storage and video streaming. Had been using Cloud SQL as my managed db and now running Postgres on my own dedicated hardware. I was forced to move away from the cloud primarily because of the high cost of running video processing(not because Cloud SQL was bad) but instead have discovered self hosting the db isnt as difficult as its made out to be. And there was a daily charge of keeping the DB hot which I dont have now. Will be moving to a rackmount server at a datacolo in about a month so this was great to read and confirms my experience.
• darksaints 11mo ago
  honestly at this point I'm actually surprised that there aren't specialized linux distributions for hosting postgres. There's so many kernel-level and file-system level optimizations that can be done that significantly impact performance, and the ability to pare down all of the unneeded stuff in most distributions would make for a pretty compact and highly optimized image.
• mind-blight 11mo ago
  I think a big piece missing from these conversations is compliance frameworks and customer trust. Of your selling to enterprise customers or governments, they want to go through your stack, networking, security, audit logs, and access controls with a fine toothed comb. Everything you do that isn't "normal" is another conversation you need to have with an auditor plus each customer. Those eat up a bunch of time and deals take longer to close. Right or wrong, these decisions make you less "serious" and therefore less credible in the eyes of many enterprise customers. You can get around that perception, but it takes work. Not hosting on one of the big 3 needs to be decided with that cost in mind
• yomismoaqui 11mo ago
  Now for the next step... just use SQLite (it's possible it will be enough for your case). Disclaimer: there's no silver bullet, yadda yadda. But SQLite in WAL mode and backups using Litestream have worked perfectly for me.
• esseph 11mo ago
  (This is very reductionist) A lot of this comes down to devs not understanding infrastructure and infrastructure components and the insane interplay and complexity. And they don't care! Apps, apps apps, developers, developers, developers! On the managerial side, it's often about deflection of responsibility for the Big Boss. It's not part of the app itself it can be HARD, and if you're not familiar with things, then it's also scary! What if you mess up? (Most apps don't need the elasticity, or the bells and whistles, but you're paying for them even if you don't use them, indirectly.)
• evnp 11mo ago
  Enjoyed the article, and the "less can be more than you think" mindset in general. To the author - on Android Chrome I seem to inevitably load the page scrolled to the bottom, footnotes area. Scrolling up, back button, click link again has the same results - I start out seeing footnotes. Might be worth a look.
• lofaszvanitt 11mo ago
  I was on a severely restricted budget and self hosted everything for 15+ years, while the heavily used part of the database was on a RAM card. The RAM drive was soft raided to a hard drive pair which were 3Ware raid1 hdds, just in case, and also did a daily backup on the database and during that time never had any data loss and never had to restore anything from backup. And my options were severely restricted due to a capped income. The real downside wasn't technical. The constant background anxiety you had to learn to live with, since the hosted news sites were hammered by the users. The dreaded SMS alerts saying the server was inaccessible (often due to ISP issues) or going abroad meant persuading one of your mates to keep an eye on things just in case, created a lot of unnecessary stress. AWS is quite good. It has everything you need and removes most of that operational burden, so the angst is much lower, but the pricing is problematic.
• reilly3000 11mo ago
  I think we can get to the point where we have self-hosted agents that can manage db maintenance and recovery. There could be regular otel -> * -> Grafana -> ~PagerDuty -> you and TriageBot which would call specialists to gather state and orchestrate a response. Scripts could kick off health reports and trigger operations. Upgrades and recovery runbooks would be clearly defined and integration tested. It would empower personal sovereignty. Someone should make this in the open. Maybe it already exists, there are a lot of interesting agentops projects. If that worked 60% of the time and I had to figure out the rest, I’d self host that. I’d pay for 80%+.
  • fullstackchris 10mo ago
    this is basically supabase. their entire stack (and product) can be hosted as a series of something like 10+ docker containers: https://supabase.com/docs/guides/self-hosting/docker https://supabase.com/docs/guides/self-hosting/docker however, like always, 'complexity has to live somewhere'. I doubt even Opus 4.5 could handle this. as soon as you get into database records themselves, context is going to blow up and you're going to have a bad time
• devin 10mo ago
  What irks me about so many comments in this thread is that they often totally ignore questions of scale, the shape of your workloads, staffing concerns, time constraints, stage of your business, whether you require extensions, etc. There is a whole raft of reasons why you might be a candidate for self-hosting, and a whole raft of reasons why not. This article is deeply reductive, and so are many of the comments.
  • groundzeros2015 10mo ago
    Engineers almost never consider any of those questions. And instead deploy the maximally expensive solution their boss will say ok to.
    • RadiozRadioz 10mo ago
      Bad, short-sighted engineers will do that. An engineer who is not acting solely in the best interests of the wider organisation is a bad one. I would not want to work with a colleague who was so detached from reality that they wouldn't consider all GP's suggested facets. Engineering includes soft/business constraints as well as technical ones.
      • npn 10mo ago
        I bet you also believe database is the single source of truth, right?
      • groundzeros2015 10mo ago
        We are saying similar things.
        • RadiozRadioz 10mo ago
          Ah, you are implying that most engineers are bad, I see. In that case I agree too
          • 10mo ago
• roncesvalles 10mo ago
  I'd argue forget about Postgres completely. If you can shell out $90/month, the only database you should use is GCP Spanner (yes, this also means forget about any mega cloud other than GCP unless you're fine paying ingress and egress). And for small projects, SQLite, rqlite, or etcd. My logic is either the project is important enough that data durability matters to you and sees enough scale that loss of data durability would be a major pain in the ass to fix, or the project is not very big and you can tolerate some lost committed transactions. A consensus-replication-less non-embedded database has no place in 2025. This is assuming you have relational needs. For non-relational just use the native NoSQL in your cloud, e.g. DynamoDB in AWS.
  • rikafurude21 10mo ago
    You seem insanely miscalibrated. $90 gets you a dedicated server that covers most projects' needs. data durability isnt some magic that only cloud providers can get you.
    • roncesvalles 10mo ago
      If you can lose committed transactions in case of single node data failure, you don't have durability. Then it comes down to do you really care about durability.
• reillyse 10mo ago
  Disk read write performance is also orders of magnitude better/cheaper/faster.
• 999900000999 10mo ago
  I've had to set up postgres manually ( before docker TBF) and it's best described as suffering. Things will go wrong. And it's all your fault. You can't just blame AWS. Also are we changing the definition of self hosting. Self hosting on Digital Ocean ?!
• bluepuma77 10mo ago
  From my point of view the real challenge comes when you want high availability and need to setup a Postgres cluster. With MongoDB you simply create a replicaset and you are done. When planing a Postgres cluster, you need to understand replication options, potentially deal with Patroni. Zalandos Docker Spilo image is not really maintained, the way to go seems CloudNativePG, but that requires k8s. I still don’t understand why there is no easy built-in Postgres cluster solution.
• geldedus 10mo ago
  Pros self-host their DB's
• conradfr 10mo ago
  I've been self hosting Postgresql for 12+ years at this point. Directly on bare metal then and now in a container with CapRover. I have a cron sh script to backup to S3 (used to be ftp). It's not "business grade" but it has also actually NEVER failed. Well once, but I think it was more the container or a swarm thing. I just destroyed and recreated it and it picked up the same volume fine. The biggest pain point is upgrading as Postgresql can't upgrade the data without the previous version installed or something. It's VERY annoying.
• pellepelster 10mo ago
  I have spent quite some time the past months and years to deploy Postgres databases to non-hyperscaler environments. A popular choice for smaller workloads has always been the Hetzner cloud which I finally poured into a ready-to-use Terraform module https://pellepelster.github.io/solidblocks/hetzner/rds/index.html https://pellepelster.github.io/solidblocks/hetzner/rds/index.... Main focus here is a tested solution with automated backup and recovery, leaving out the complicated parts like clustering, prioritizing MTTR over MTBF. The naming of RDS is a little bit presumptuous I know, but it works quite well :-)
• sergiotapia 10mo ago
  Some fun math for you guys. I had a single API endpoint performing ~178 Postgres SQL queries. Setup Latency/query Total time ------------------------------------------------- Same geo area 35ms 6.2s Same local network 4ms 712ms Same server ~0ms 170ms This is with zero code changes, these time shavings are coming purely from network latency. A lot of devs lately are not even aware of latency costs coming from their service locations. It's crazy!
• Beltiras 10mo ago
  I've had my hair on fire because my app code shit the bed. I've never ever (throughout 15 years of using it in everything I do) had to even think about Postgres, and yes, I always set it up self-hosted. The only concern I've had is when I had to do migrations where I had to upgrade PG to fit with upgrades in the ORM database layer. Made for some interesting stepping-stone upgrades once in a while but mostly just careful sysadmining.
• fbuilesv 10mo ago
  I would have liked to read about the "high availability" that's mentioned a couple of times in the article; the WAL Configuration section is not enough, and replication is expensive'ish.
• raggi 10mo ago
  I have been self hosting a product on Postgres that serves GIS applications for 20 years and that has been upgraded through all of the various versions during that time. It has a near perfect uptime record modulo two hardware failures and short maintenance periods for final upgrade cutovers. The application has real traffic - the database is bigger than those at my day job.
• jeffbee 10mo ago
  The author's experience is trivial, so it indicates nothing. Anybody can set up a rack of postgresql servers and say it's great in year 2. All the hardware is under warranty and it still works anyway. There haven't been any major releases. The platform software is still "LTS". Nobody has needed to renegotiate the datacenter lease yet. So experience in year 2 tells you nothing.
• jbmsf 10mo ago
  I started in this industry before cloud was a thing. I did most of the things RDS does the hard way (except being able to dynamically increase memory on a running instance, that's magic to me). I do not want that responsibility, especially because I know how badly it turns out when it's one of a dozen (or dozens) of responsibilities asked of the team.
• fhcuvyxu 10mo ago
  > Self-hosting a database sounds terrifying. Is this really the state of our industry? Lol. Bunch of babies scared of the terminal.
• vbezhenar 10mo ago
  I don't feel like it's easy to self-host postgres. Here are my gripes: 1. Backups are super-important. Losing production data just is not an option. Postgres offers pgdump which is not appropriate tool, so you should set up WAL archiving or something like that. This is complicated to do right. 2. Horizontal scalability with read replicas is hard to implement. 3. Tuning various postgres parameters is not a trivial task. 4. Upgrading major version is complicated. 5. You probably need to use something like pgbouncer. 6. Database usually is the most important piece of infrastructure. So it's especially painful when it fails. I guess it's not that hard when you did it once and have all scripts and memory to look back. But otherwise it's hard. Clicking few buttons in hoster panel is much easier.
  • nrhrjrjrjtntbt 10mo ago
    Scaling to a different instance size is also easy on AWS. That said a self hosted DB on a dedicated Hetzner flies. It does things at the price that may save you time reworking your app to be more efficient on AWS for cost. So swings and roundabouts.
  • tonyhart7 10mo ago
    "all scripts and memory to look back. But otherwise it's hard. Clicking few buttons in hoster panel is much easier." so we need open source way to do that, coolify/dokploy comes to mind and it exactly do that way I would say 80% of your point wouldnt be hit at certain scale, as most application grows and therefore outgrow your tech stack. you would replace them anyway at some point
  • npn 10mo ago
    wal archiving is piss easy. you can also just use basebackup. with postgres 17 it is easier than ever with incremental backup feature. you don't need horizontal scalability when a single server can have 384 cpu real cores, 6TB of ram, some petabytes of pcie5 ssd, 100Gbps NIC. for tuning postgres parameters, you can start by using pgtune.leopard.in.ua or pgconfig.org. upgrading major version is piss easy since postgres 10 or so. just a single command. you do not need pgbouncer if your database adapter library already provide the database pool functionality (most of them do). for me maintained database also need that same amount of effort, due to shitty documents and garbage user interfaces (all aws, gcp or azure is the same), not to mention they change all the time.
• npn 10mo ago
  > I sleep just fine at night thank you. I also self-host my webapp for 4+ years. never have any trouble with databases. pg_basebackup and wal archiving work wonder. and since I always pull the database (the backup version) for local development, the backup is constantly verified, too.
• taylorsatula 10mo ago
  Self-hosting Postgres is so incredibly easy. People are under this strange spell that they need to use an ORM or always reach for SQLite when it’s trivially easy to write raw SQL. The syntax was designed so lithium’d out secretaries were able to write queries on a punchcard. Postgres has so many nice lil features.
• kwillets 10mo ago
  Over time I've realized that the best abstraction for managing a computer is a computer.
• nottorp 10mo ago
  > These settings tell Postgres that random reads are almost as fast as sequential reads on NVMe drives, which dramatically improves query planning. Interesting. Whoever wrote https://news.ycombinator.com/item?id=46334990 https://news.ycombinator.com/item?id=46334990 didn't seem to be aware of that.
• drchaim 10mo ago
  I’ve been managing a 100+ GB PostgreSQL database for years. Each two years I upgrade the VPS for the size, and also the db and os version. The app is in the same VPS as the DB. A 2 hour window each two years is ok for the use case. No regrets.
• lukaslalinsky 10mo ago
  I'm not a cloud-hosting fan, but comparing RDS to a single instance DB seems crazy to me. Even for a hobby project, I couldn't accept losing data since the last snapshot. If you are going to self-host PostgreSQL in production, make sure you have at least some knowledge how to setup streaming replication and have monitoring in place making sure the replication works. Ideally, use something like Patroni for automatic failover. I'm saying this a someone running fairly large self-hosted HA PostgreSQL databases in production.
  • tgtweak 10mo ago
    RDS is not, by default, multi-instance and multi-region or fault tolerant at all - you choose all of that in your instance config. The amount of single-instance single-region zero-backup RDS setup's I've seen in the wild is honestly concerning. Do Devs think an RDS instance on it's own without explicit configuration is fault tolerant and backed-up? If you have an ec2 instance with EBS and auto-restart you have almost identical fault tolerance (yes there are some slight nuances on RDS regarding recovery following a failure). Just found that assumption a bit dangerous. The ease with which you can set that up is easy on RDS but it's not on by default.
• jillesvangurp 10mo ago
  There are a couple of things that are being glossed over: Hardware failures and automated fail overs. That's a thing AWS and other managed hosting solutions do. Hardware will eventually fail of course. In AWS this would be a non event. It will fail over, a replacement spins up, etc. Same with upgrades, and other stuff. Configuration complexity. The author casually outlines a lot of fairly complex design involving all sorts of configuration tweaks, load balancing, etc. That implies skills most teams don't have. I know enough to know that I have quite a bit of reading up to do if I ever were to decide to self host postgresql. Many people would make bad assumptions about things being fine out of the box because they are not experienced postgresql DBAs. Vacations/holidays/sick days. Databases may go down when it's not convenient to you. To mitigate that, you need to have several colleagues that are equally qualified to fix things when they go down while you are away from keyboard. If you haven't covered that risk, you are taking a bit of risk. In a normal company, at least 3-4 people would be a good minimum. If you are just measuring your own time, you are not being honest or not being as diligent as you should be. Either it's a risk you are covering at a cost or a risk you are ignoring. With managed hosting, covering all of that is what you pay for. You are right that there are still failure modes beyond that that need covering. But an honest assessment of the time you, and your team, put in for this adds up really quickly. Whatever the reasons you are self hosting, cost is probably a poor one.
• vitabaks 10mo ago
  Just use Autobase for PostgreSQL https://github.com/vitabaks/autobase https://github.com/vitabaks/autobase automates the deployment and management of highly available PostgreSQL clusters in production environments. This solution is tailored for use on dedicated physical servers, virtual machines, and within both on-premises and cloud-based infrastructures.
• banditelol 10mo ago
  One of the things that made me think twice for self hosting postgres is securing the OS I host PG on. Any recommendation where to start for that?
  • danparsonson 10mo ago
    Can you get away without exposing it to the internet? Firewall it off altogether, or just open the address of a specific machine that needs access to it?
• PunchyHamster 10mo ago
  Cooking the RDS equivalent is reasonable amount of work, and pretty big amount of knowledge (easy to make failover solution have lower uptime than "just a single VM" if you don't get everything right) ... but you can do a lot with just "a single VM and robust backup". PostgreSQL restore is pretty fast, and if you automated deployment you can start with it in minutes, so if your service can survive 30 minutes of downtime once every 3 years while the DB reloads, "downgrading" to "a single cloud VM" or "a single VM on your own hardware" might not be a big deal.
• jgalt212 10mo ago
  Does anyone offer a managed database service where the database and your application server live on the same box? Until, I can get such latency advantages of such a set-up, we've found latency just too high to go with a managed solution. We are already spending too much batching or vectorizing database reads.
• yoan9224 10mo ago
  I've been self-hosting Postgres for production apps for about 6 years now. The "3 AM database emergency" fear is vastly overblown in my experience. In reality, most database issues are slow queries or connection pool exhaustion - things that happen during business hours when you're actively developing. The actual database process itself just runs. I've had more AWS outages wake me up than Postgres crashes. The cost savings are real, but the bigger win for me is having complete visibility. When something does go wrong, I can SSH in and see exactly what's happening. With RDS you're often stuck waiting for support while your users are affected. That said, you do need solid backups and monitoring from day one. pgBackRest and pgBouncer are your friends.
• _ea1k 10mo ago
  I often find it sad how many things that we did, almost without thinking about them, that are considered hard today. Take a stroll through this thread and you will find out that everything from RAID to basic configuration management are ultrahard things that will lead you to having a bus factor of 1. What went so wrong during the past 25 years?
• cosmodust 10mo ago
  I would suggest if you do host your database yourself consider taking the data seriously. Few easy solutions are using a multi zonal disk [1] with scheduled automatic snapshots [2]. [1] https://docs.cloud.google.com/compute/docs/disks/hd-types/hyperdisk-balanced-ha https://docs.cloud.google.com/compute/docs/disks/hd-types/hy... [2] https://docs.cloud.google.com/compute/docs/disks/create-snapshots https://docs.cloud.google.com/compute/docs/disks/create-snap...
  • deleted 10mo ago
    [deleted]
  • cube00 10mo ago
    Scheduled automatic snapshots are not the kind of consistent snapshots you need for a filesystem based backup.
    • cosmodust 10mo ago
      Snapshots might break ACID for last few transactions but it will flush all in-memory writes before taking the freeze. Consider its 1 click solution, its good enough than losing everything?
• anonu 10mo ago
  does self-hosting on EC2 instance count?
• tgtweak 10mo ago
  As someone who self hosted mysql (in complex master/slave setups) then mariadb, memsql, mongo and pgsql on bare metal, virtual machines then containers for almost 2 decades at this point... you can self host with very little downtime and the only real challenge is upgrade path and getting replication right. Now with pgbouncer (or whatever other flavor of sql-aware proxy you fancy) you can greatly reduce the complexity involved in managing conventionally complex read/write routing and sharding to various replicas to enable resilient, scalable production-grade database setups on your own infra. Throw in the fact that copy-on-write and snapshotting is baked into most storage today and it becomes - at least compared to 20 years ago - trivial to set up DRS as well. Others have mentioned pgBackRest and that further enforces the ease with which you can set up these traditionally-complex setups. Beyond those two significant features there isn't many other reasons you'd need to go with hosted/managed pgsql. I've yet to find a managed/hosted database solution that doesn't have some level of downtime to apply updates and patches so even if you go fully hosted/managed it's not a silver bullet. The cost of managed DB is also several times that of the actual hardware it's running on, so there is a cost factor involved as well. I guess all this to say it's never been a better time to self-host your database and the learning curve is as shallow as it's ever been. Add to all of this that any garden-variety LLM can hand-hold you through the setup and management, including any issues you might encounter on the way.
• jpgvm 10mo ago
  Beyond the usual points there are some other important factors to consider self-hosting PG: 1. Access to any extension you want and importantly ability to create your own extensions. 2. Being able to run any version you want, including being able to adopt patches ahead of releases. 3. Ability to tune for maximum performance based on the kind of workload you have. If it's massively parallel you can fill the box with huge amounts of memory and screaming fast SSDs, if it's very compute heavy you can spec the box with really tall cores etc. Self hosting is rarely about cost, it's usually about control for me. Being able to replace complex application logic/types with a nice custom pgrx extension can save massive amounts of time. Similarity using a custom index access method can unlock a step change in performance unachievable without some non-PG solution that would compromise on simplicity by forcing a second data store.
• the-anarchist 10mo ago
  I generally agree with the author, however, there are a handful of relatively prominent, recent examples (eg [1]) that many admins might find scary enough to prefer a hosted solution. [1]: https://matrix.org/blog/2025/07/postgres-corruption-postmortem/ https://matrix.org/blog/2025/07/postgres-corruption-postmort...
• polskibus 10mo ago
  What's the SOTA for on-prem Postgres, in terms of point-in-time-recovery? are there any well-tested tools for it?
• ttkciar 10mo ago
  Huh. I thought hosting one's own databases was still the norm. Guess I'm just stuck in the past, or don't consume cloud vendor marketing, or something. Glad my employer is still one of the sane ones.
• klooney 10mo ago
  Looking at this list: Standard Postgres compiled with some AWS-specific monitoring hooks A custom backup system using EBS snapshots Automated configuration management via Chef/Puppet/Ansible Load balancers and connection pooling (PgBouncer) Monitoring integration with CloudWatch Automated failover scripting Every company I've ever on boarded at, that hosted their own database, had number one, and a lot of TODOs around the rest. It's really hard! Honestly, it could be a full time job for a team. And that's more expensive than RDS.