Can't wait to have it available in RDS in 2030.
PostgreSQL 16 Beta 1
11–20 of 62 posts
Re: PostgreSQL 16 Beta 1
#12This is an exciting release to be sure. Very happy to see that the CPU improvements include ARM, diversity is good! Given the current release pace, I'd love to have another upgrade path than `pg_dump | psql`. That would remove a great deal of friction in prod.
> I'd love to have another upgrade path than `pg_dump | psql`
pg_upgrade
Re: PostgreSQL 16 Beta 1
#13Postgresql is amazing but I must say the last few updates have been a bit disappointing. Still waiting for automatic incremental updates for materialized views - been worked on for several years but still not released! https://wiki.postgresql.org/wiki/Incremental_View_Maintenanc... https://github.com/sraoss/pg_ivm
To be fair view update is a very hard problem in computer science. It's not as though it's just a lack of time to implement it.
Re: PostgreSQL 16 Beta 1
#14Postgresql is amazing but I must say the last few updates have been a bit disappointing. Still waiting for automatic incremental updates for materialized views - been worked on for several years but still not released! https://wiki.postgresql.org/wiki/Incremental_View_Maintenanc... https://github.com/sraoss/pg_ivm
On the one hand, I totally understand.
On the other, it's pretty confidence-inspiring that they don't put stuff in until they're sure it's ready.
Re: PostgreSQL 16 Beta 1
#15[flagged]
It can be. We still running PG11 and 13 in production. Not obligated to upgrade - especially when the software is rock solid.
Re: PostgreSQL 16 Beta 1
#16This is an exciting release to be sure. Very happy to see that the CPU improvements include ARM, diversity is good! Given the current release pace, I'd love to have another upgrade path than `pg_dump | psql`. That would remove a great deal of friction in prod.
> I'd love to have another upgrade path than `pg_dump | psql` pg_upgrade
Or logical replication to the new box then migrate traffic.
Re: PostgreSQL 16 Beta 1
#17Can't wait to have it available in RDS in 2030.
AWS has gotten much better in recent years. Pg15 is available on Aurora as of last month. That's about 6-7 months after it was released, a significant improvement over years past.
Re: PostgreSQL 16 Beta 1
#18For being "boring and stable" technology, Postgres 16 includes 200 features, which is on par with each of prior years releases. If you're looking for the full set of features it's available here - https://www.postgresql.org/docs/16/release-16.html . Personal favorites on the list include: - load_balance_hosts, which is an improvement to libpq so you can load balance across multiple Postgres instances. - Logical repli…
Could you elaborate on the load balancing? Is this a replacement for PG bouncer and similar?
IMO the biggest reason folks use pgbouncer is not for load balancing (which it can do, -ish) but instead for connection pooling. Postgres connections are expensive for the db server (one process per connection not one thread) so if you have say thousands of web application pods you need to use pgbouncer or similar as a proxy to multiplex those thousands of connections down onto a more manageable number (~200). So no, not really.
(EDIT: if you don't know this already - the _establishment_ of connections is also super expensive. so another reason to pgbounce is to keep connections persistent if you have app servers that are constantly opening and closing conns, or burst open conns, or such like. Even if the total conns to pg doesnt go super high, the cost of constantly churning them can really hurt your db)
Re: PostgreSQL 16 Beta 1
#19[flagged]
Whenever you do a one day full of updates and fix small issues but also gain new features and performance, just remember there is someone who uses some super old db no one wanna touch it again and the migration of that old thing will take weeks!
Re: PostgreSQL 16 Beta 1
#20[flagged]
PG 15 has an EOL of Nov 2027, so you should be ok to stick with it for a while. ;)