Scaling with PostgreSQL without boiling the ocean

Scaling with PostgreSQL without boiling the ocean(shayon.dev)

40 points by plaur782 1 year ago | 14 comments

jappgar 1 year ago |

How it started:

> Scaling PostgreSQL successfully doesn’t always require a full team of DBAs and experts.

How it's going:

> Monitor TOAST table sizes and access patterns via pg_stat_sys_tables

Don't get me wrong, this is a good article I wish I read three years ago, but this is 100% expert level stuff that glazes the eyes of the average CRUD dev.

shayonj 1 year ago | |

You do make a good point - I think there is something to be said about making things more easier for application/product engineers such that these things are sort of "auto pilot"

shayonj 1 year ago |

hey hey! thanks for reading and posting to HN - (post author)

kyrra 1 year ago | |

FYI, The "Stop Relying on IF NOT EXISTS for Concurrent Index Creation in PostgreSQL" link points to localhost.

Also, consider using a tool like this: https://pub.dev/documentation/linkcheck/latest/

shayonj 1 year ago | | |

oops! (:p) fixed, thanks!

aetherson 1 year ago |

I mean, these are all useful techniques for scaling Postgres, but, like... they're also a list of why scaling Postgres is hard.

paulryanrogers 1 year ago | |

FWIW some of these also apply to MySQL, like the use of FKs and major version upgrades. I think scaling any centralized and business-critical resource is hard.

aetherson 1 year ago | | |

Sure, any relational, ACID database is going to be hard to scale. But of the ones that people actually use a lot, Postgres is the hardest.

lukaslalinsky 1 year ago | |

Scaling any database is hard. With databases specifically built for scaling horizontally, you pay the price up front as the infrastructure is complex. Don't get fooled by "run this docker image on N servers" instructions. Even with heavily automated deployments, if you don't know the architecture and what is doing what, you will hit issues.

snailmailstare 1 year ago | | |

When I worked with nosql I always thought switching to postgres was the way to go since whatever nosql devs do essentially gets a competitive feature integrated into postgres. But when you look beyond the core, postgres seems like it lets any terrible hack fill a role..

I mean why can't I setup a few interconnected databases and send my write commands to any one of them and have them succeed or fail with normal transaction semantics obscuring unnecessary details? I think every modern attempt at a non trivial database has a better solution than Patroni.