Looking Ahead to Postgres 19

The clear baseline view was that Postgres has become the default serious relational database for new work. People contrasted it with Oracle, MySQL, MariaDB, and SQL Server, usually in Postgres’s favor. Oracle drew the usual hostility over cost, lock-in, and old design scars. MySQL and MariaDB were criticized for a long tail of operational and SQL rough edges that are survivable in legacy systems but hard to justify on fresh projects. SQL Server got more respect. Several people still think it has standout features, especially indexed views, clustered indexes, plan caching, query hints, and polished tooling for .NET shops. Even there, the center of gravity has shifted. The practical appeal of Linux-native operation, open source flexibility, managed service options, and the broader Postgres ecosystem now outweighs Microsoft’s old integrated-stack advantage for many teams. Where people still felt genuine pain was specific and recurring. Postgres connections remain heavyweight because each session is a process, so poolers are still part of the architecture in a way they are not for SQL Server. Incremental, synchronously maintained materialized views came up over and over as a missing piece. Teams described hand-rolled trigger systems as brittle, race-prone, and hard to keep correct under concurrency. SQL Server’s indexed views were held up as the feature people miss most when moving to Postgres because they keep derived data in sync without the stale-data traps of manual refresh logic. The other major gap was storage layout. Users with very large scientific and analytical datasets said row-oriented storage is becoming the limiting factor, and while pluggable storage and extensions hint at a path forward, Postgres still does not offer a native columnar answer in core. That led to a sharper line about what Postgres should become. Many people want one operational center of gravity, with row, columnar, graph, time-travel, and specialized indexing all reachable from the same database. Others think this is exactly how databases turn into bloated compromises, and that analytics at real scale still belongs in systems like ClickHouse or DuckDB, fed by change data capture from Postgres. The useful consensus was not ideological. Postgres keeps expanding because it is the tool many teams already trust, and the cost of moving 100s of TB and retraining workflows is real. But when your hottest tables or queries stop fitting the row-store model, treating Postgres as the transactional core and pushing older or analytical data elsewhere is often the saner move than waiting for core to become every database at once. A side thread fixated on the blog’s writing style and whether it was AI-generated. That got plenty of annoyance, but it did not add much technical signal beyond a broader fatigue with vendor content that sounds generic and overproduced.