Looking Ahead to Postgres 19

I've used Postgres, Oracle, MsSql Server, and MySql in serious projects, no extensive experience with Sqlite, which I know is an amazing player.

These days, I do myself a favor and always avoid Oracle and MySql/MariaDB.

Postgres is amazing, and the two big things I wished it had:

1. lightweight connection; connection bouncers improve the situation, but you still have an unreasonably high memory footprint per concurrent connection.

2. Synchronously updated materialized views (Sql Server calls them indexed views). These are incredible tools in complex data situations. I saw a project struggle with complex technical implementations that would be elegant, trivial and always correct with indexed views.

Sql Server can be costly, but in many cases the benefits it provides are totally worth the cost.

Choosing the data store carefully prevents lots of future trouble.

Speaking as long-term (>15 years) user of Postgres in science, I am getting worried about the lack of columnar type of storage in Postgresql. As the datasets become bigger and bigger, the limitations of PG's storage are becoming more and more significant. I know there are various extensions (i.e. cetus) that may offer such functionality, but then you depend on that extension being supported in the future, as well additional complexity.

No word that PostgreSQL 19 introduces native application-time temporal data support based on the SQL:2011 standard? https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-...

i like the COPY and logical replication improvements. Currently I back up my PG database with a sidecar Databasus instance that is heavier than my entire backend + DB + Caddy!

(LLM writing rant below)

---

> That alone tells you something: Users had a real need, and the ecosystem filled the gap.

> This sounds straightforward, but it solves a real operational problem.

> None of these change the world. All of them make day-to-day data workflows better.

> The easy thing to do here is list planner changes and call it done. But the more useful takeaway is this: Postgres keeps getting better at recognizing the shape of common queries and doing less unnecessary work.

> [Proceed to list planner changes]

If Orwell were alive today, he might declare himself illiterate in English and learn Klingon just to avoid having to read these.

The graph database feature looks interesting, but I wonder...

SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));

That is _awful_ syntax; it is reminiscent of neo4j, which is surely not a tool anyone serious should copy from outright in 2026.

And of course the final thing I am left wondering is if it's fast. Row-level security is such a useful feature and yet only a fool would contemplate building anything serious with Postgres', as the planner goes haywire and does per-row-matching, nuking performance.

It's great to see GROUP BY ALL introduced which, AFAIK, was a concept introduced by DuckDB.

> Several of these features were first introduced by DuckDB, while some are inspired by other systems. Many of the features originally introduced by DuckDB (e.g., GROUP BY ALL) have been since adapted by other systems.

https://duckdb.org/docs/lts/sql/dialect/friendly_sql

It's funny that, "GROUP BY ALL" makes a lot of sense but it had never crossed my mind before!

I can't decide whether this person writes in the type of style that was apparently overrepresented in LLM training, or whether they heavily used AI to spruce up their writing. I'm learning towards the latter.

I'm wondering. Just wondering? Will they ever support multiple storage engines like MariaDB? Having a storage engine that support OLTP or OLAP or append-only would be cool. I totally understand if they don't want to do that.

The Authors avatar looked familiar, crunchydata ?

I'm dreaming of block compression in Postgresql, instead of only row compression, too limited to be effective. I know you can store your data on a Zfs pool with block compression, but having it native would remove the burdain of setting this up and maybe better perf.

I am looking forward to the day it supports table access methods that enables variety of use cases out of box.

Something like rocksdb as PG backend would be fantastic. Yugabyte does this but it's not PG.

Oh my, finally a reason to upgrade from 16.

This looks amazing, we've been using Postgres in production for the last two years on a fairly high-volume system and it's been fantastic.