A practical guide to what's actually changing in PostgreSQL 19, covering six compatibility breaks you need to know before upgrading and four SQL features worth using once you do. The author tested everything against Beta 3 and explains what each change means for your workload.

• Six breaking changes ship in PG 19: JIT disabled by default, standard_conforming_strings forced on, RADIUS auth removed, MD5 warnings enabled, inet/cidr GiST indexes rebuilt, and max_locks_per_transaction doubled—most are silent behavior shifts that break things only if you don't know to look.
• FOR PORTION OF lets you split and update a time-bounded row in one statement instead of hand-rolling UPDATE then INSERT, useful for temporal data like contract period changes.
• INSERT ... ON CONFLICT DO SELECT returns the conflicting row directly without a separate query, solving the common pattern of "upsert and fetch back the row" in registration flows and dedup-on-write pipelines.
• Window functions now support IGNORE NULLS to skip over NULL values and find the nearest actual value, replacing workarounds like window frame tricks or separate counters.

DuckLabs, the company behind the popular DuckDB analytics database, is being acquired by AWS in early September. The core open-source projects will remain free under the MIT license and governed by the nonprofit DuckDB Foundation, but the team gains AWS's infrastructure and reach to scale the technology further.

• DuckDB hits over 1 million downloads daily and the founders realized their bootstrapped model couldn't support the project's growth trajectory without becoming a bottleneck
• All core Duck Stack components (DuckDB, DuckLake, Quack) stay open-source under MIT license with the DuckDB Foundation maintaining stewardship
• AWS has committed long-term support and the DuckLabs team of 30+ people will remain together in Amsterdam, focusing on technical work rather than sales operations

This tool parses your SQL CREATE TABLE and ALTER TABLE statements and instantly renders an interactive ER diagram in your browser. It works entirely locally—no uploads or accounts—supports PostgreSQL, MySQL, SQLite, and SQL Server, and lets you drag tables, rename elements, and export to PNG or SVG.

• Paste SQL DDL (CREATE/ALTER, across Postgres/MySQL/SQLite/SQL Server) and get an instant interactive ER diagram, fully client-side with no uploads or accounts.
• Diagrams are editable—drag tables, rename fields, auto-layout—and correctly detect not-null, unique, and key/foreign-key constraints.
• Export options include high-res PNG, vector SVG, saved project files, or a shareable URL that embeds the diagram itself.
• Free, open source, installation-free, and works across desktop and mobile.

PostgreSQL 18 introduces temporal constraints that simplify managing time-related data, allowing developers to maintain referential integrity across temporal relationships with ease. By utilizing GiST indexes and the WITHOUT OVERLAPS constraint, developers can efficiently handle overlapping time periods in applications without complex coding.

• PostgreSQL 18 adds native temporal constraints, letting the database enforce non-overlapping time ranges without custom application logic
• The WITHOUT OVERLAPS clause combined with GiST indexes enables primary/unique keys and foreign keys that account for time periods
• This allows referential integrity to be maintained across temporal relationships (e.g., preventing overlapping bookings or contracts) directly at the database level

Maintaining consistency in a system comprised of separate databases can be challenging, particularly in the absence of transactions. The article discusses the importance of defining a system of record versus a system of reference and emphasizes the Write Last, Read First principle to ensure safety properties like consistency and traceability in financial transactions.

• Write to the system of record last, but read from it first — this ordering prevents referencing data that hasn't actually been durably committed.
• If a downstream write (e.g., to a search index or cache) fails after the system of record succeeds, that's recoverable via retries; failing in the other order risks phantom reads of uncommitted state.
• Treating one database as the authoritative system of record (vs. other systems of reference) gives you a clear conflict-resolution and recovery strategy when multiple stores disagree.