[mystraline]

Im not a proper DBA, but oversee some basic postgres installs (read: logging, monitoring, upgrades).

This appears to only have any effect with datalake style installs, where storage is separate from compute.

Not going to have any effect on those small postgres installs for that generic one off app.

[tempest_]

Everyone thinks they need a data lake when most people just need a data pond or data puddle. This is made worse by the industry disappearance of the DBA role and compounded by the fact that PG is not especially easy to tune.

All of this to say that a ton of people are on some sort of managed cloud postgres where the compute is almost always separated from the storage even for the small instances.

Neon et al. will tell you they scale, and I am sure they can but the number of enterprises that actually exceed when can be put on a few large servers in pretty low. You gotta lock them in early so their orgs never develop the expertise to move off on the off chance they get big.

[nikita]

We provide you fully managed Postgres. Lots of our customers use it for lots of small instances of Postgres since using Lakebase is so lightweight.

Small and large instances benefit from this performance optimization.

[mystraline]

Again, when the users of this app are just 3 admins, over basic metrics from ArcGIS Monitor, I dont need to deviate from their recommended, tune, or much of anything.

This isnt some high throughput app where every IOPS matters.

And in my experiences, most apps that need a database arent serving 1000's of people per hour. Most are fine with a few users per hour.

The whole "scale to scale cause youre 1 minute away from HN hug of death" is just wishful thinking a budget bloat from the hyperscalers selling 'butwhatifs'. Ive called AWS to task on their 5 pillars crap, which basically says "pay double for redundancy". Gee, I wonder why AWS would recommend customers to pay double (eyeroll).