Go ahead, self-host Postgres
pierce.dev
Go ahead, self-host Postgres
1–10 of 407 posts
Re: Go ahead, self-host Postgres
#2I've been self hosting it for 20 years. Best technical decision I ever made. Rock solid
Re: Go ahead, self-host Postgres
#3> 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
Re: Go ahead, self-host Postgres
#4Recommends 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.
Re: Go ahead, self-host Postgres
#5And 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.
Re: Go ahead, self-host Postgres
#6And 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.
Re: Go ahead, self-host Postgres
#7> 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 wai…
This is also the basis for most SaaS purchases by large corporations. The old "Nobody gets fired for choosing IBM."
Re: Go ahead, self-host Postgres
#8Recommends 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.
There's not much to recommend; just use the Postgres from your distribution's LTS repo. I like Debian for its rock solid stability.
Re: Go ahead, self-host Postgres
#9And 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.
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.
Re: Go ahead, self-host Postgres
#10Recommends 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.
There's not much to recommend; just use the Postgres from your distribution's LTS repo. I like Debian for its rock solid stability.
Patroni, Pigsty, Crunchy, CloudNativePG, Zalando, ...