Scaling with PostgreSQL without boiling the ocean

[jappgar]

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]

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]

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

[kyrra]

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/

[aetherson]

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

[paulryanrogers]

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.

[lukaslalinsky]

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.