[jasoncartwright]

After coming back to coding after ~10-15 years away, databases are IMHO the most improved element of the dev/devops experience.

Managed Postgres on Google Cloud is a fantastic product (I'm sure other cloud's offerings are also similarly good). Backups, replication, point-in-time recovery, managed updates, plus quick & easy system & query insight tooling. All for less than £1/day.

[eerikkivistik]

While I do love Postgres and use it daily on AWS and Google Cloud, I will add that the managed Postgres on Google Cloud is a mess in some areas. For example they use some EOL extensions outdated for 10+ years (a specific example is GEOS) and refuse to update it and give no control for you to upgrade it either.

[refset]

I wonder where things will stand in 10 years from now. Will many orgs still be consuming vanilla Postgres, or will most workloads have shifted to ~proprietary implementations behind cloud services like "Aurora PostgreSQL Limitless Database" and "Google AlloyDB for PostgreSQL" due to unrivalled price-performance? In other words, can progress in OSS Postgres keep up with cloud economics or will things devolve into an even messier ecosystem centred purely around the wire protocol and SQL dialect?

[PittleyDunkin]

Databases seem to grow much slower than other assets, so maybe this price advantage just won't be worth the vendor lockin. Hell my current extremely valuable postgres database worth literally millions of dollars is about thirteen gigs and could be hosted on my mac mini if I really wanted to. Still, the managed hosting is worth it—only without vendor lockin!

[ethbr1]

DBMS (and DBAs) tend to be more conservative, so extensions and implementations diverge much more slowly than, say, js.

There's also the incoming business argument in favor of not diverging too far from baseline.

If I'm AWS/Azure/GCP trying to attract a customer from a competitor service, 'completely rewrite your app to be able to use us' isn't a compelling pitch.

MS SQL Server and Oracle have different incentives, but the cloud services would probably prefer portability and decreased maintenance / fork support load.

[cpursley]

If you think those are nice, check out neon.tech - set up was faster than any of the big cloud providers.

[jasoncartwright]

Unfortunately they don't have anything in a region where my code runs. Interesting though!

[nikita]

(neon ceo). What region are you in?

[jasoncartwright]

Hi! London.

[nikita]

Oh, that's coming very very soon! London and San Paolo. Def in Q1.

[andruby]

I love PG. PostgreSQL already had most of its great features 15 years ago.

Anything new that you particularly enjoy?

[jasoncartwright]

I guess it's the zero-hassle managed service that's the improvement rather than the DBMS itself

[edoceo]

jsonb

[happymellon]

At 10 years, it is newer than 15 but its not a new feature by a long shot.

[tmountain]

RLS (row level security) came out in 9.5, January 2016. It's a game changer when used in combination with JWT tokens for identity and something like PostgREST. Specifically because a client can talk directly to PostgREST and run queries directly against the DB while letting the RLS policies dictate access. Example, a mobile client is allowed to insert data on the auth'd user's behalf, but the same user can only access rows that are associated with their own identity. Supabase rolls this up into an out of the box solution, which basically eliminates a lot of work writing "middleware APIs".

[hoppp]

Its a good feature but I spent many days debugging problems caused with it. It might have been the fault of supabase.js apis , but still not a lot of fun memories.

[tmountain]

It's like a lot of things... process orientation and discipline early on go a long way to keeping things sane. There are nice techniques for debugging policies as well (login_as_user functions, etc). We write pgTap tests for everything, and that REALLY helps.

[edoceo]

It's been available for less than half the time I've been using PostgreSQL. I stil consider it new.