Looking Ahead to Postgres 19

Original Article ↗ Hacker News Discussion ↗

Perceived omissions and notable PG19/PG roadmap features

  • Commenters note the article underemphasizes major additions like native application‑time temporal tables (SQL:2011 style) and query hints, which previously generated interest.
  • New graph querying (SQL/PGQ) draws attention; some find the syntax unwieldy and question performance, especially given past planner issues with row‑level security.
  • GROUP BY ALL is widely praised as a small but very handy SQL usability improvement.
  • Improvements to COPY and logical replication are welcomed for lighter backups; some already run heavy sidecar instances just for backup.
  • Async I/O in PG18 was cited as a strong motivator to move off 16.

AI‑generated content and HN discussion quality

  • A large subthread debates whether the post is LLM‑written. Some rely on tools like Pangram; others stress such detectors aren’t reliable proof.
  • Several people are frustrated by what they see as generic “LLM slop” prose becoming common on HN, with many different blogs now sharing the same tone and structure.
  • Others argue meta‑complaints about AI are lower‑value than engaging with technical content, though defenders say spotting non‑novel, AI‑washed work is aligned with HN norms.
  • There is mention that Snowflake laid off technical writers, citing AI, and concerns about misleading human authorship claims.

Postgres vs. other databases

  • Many production users are enthusiastic about Postgres but still want:
    • Lightweight connections (process‑per‑connection seen as heavy vs. threaded servers).
    • Synchronously maintained materialized / indexed views like SQL Server’s.
  • SQL Server is praised for indexed views, snapshot isolation, strong tooling (SSMS, Visual Studio, RedGate), and columnstore indexes, though some find its ecosystem aging, Windows dependence painful, and MERGE semantics problematic.
  • MySQL/MariaDB criticisms include weak JSON implementation, lack of transactional DDL/merge/partial indexes, strictness issues, historical type/UTF‑8 misbehavior, and replication/DDL pain.
  • Oracle is heavily criticized for semantics like empty‑string‑equals‑NULL and for vendor/legal/commercial baggage.

Scaling, storage engines, and analytics

  • Several users want pluggable storage engines: LSM (e.g., RocksDB‑like), append‑only, or native columnar/ block compression.
  • Examples raised include Salesforce running Postgres with LSM, OrioleDB (still requiring core patches), and columnar/analytics extensions such as cetus or a new Delta‑like extension.
  • There is tension between:
    • Those who want Postgres to evolve with pluggable/columnar storage so it can handle very large scientific/analytical workloads in place.
    • Those who argue columnar OLAP databases are a different category and advise using Postgres for OLTP plus separate warehouses (ClickHouse, DuckDB, etc.) via CDC or ETL.

Operations, ecosystem, and culture

  • In‑place major version upgrades remain a pain point, especially with Docker.
  • Connection/process model vs. MSSQL’s thread model is debated in terms of scalability, robustness, and plan caching.
  • Some see Postgres as effectively displacing MySQL for new app stacks (“PHP/MySQL → Python/Postgres”) and note major data platforms (Snowflake, Databricks, ClickHouse) now offering managed Postgres, which is seen as a sign of the times.
  • A user asks for advanced Postgres learning resources; the response is that the feature surface is very broad, so recommendations depend heavily on specific interests.