DBeaver recently introduced interactive chat capabilities into the free, open-source Community Edition. What does that mean? 

It means some of your database tasks can be accomplished significantly faster! 

First, you can ask for information without coding SQL. I love Structured Query Language, but it is much faster to write this prompt:

What are the top ten most popular rentals and how much revenue did they generate?

[...]

Background

I've been working on pgjdbc, the PostgreSQL JDBC driver, for many years. It's a great driver, gets millions of monthly downloads, and it's not going anywhere.

It's also a driver whose shape was decided a very long time ago. JDBC came first and PostgreSQL came second. The JVM it was designed for had no virtual threads, no records, and no sealed types. Most of what you'd want to change about that today can't be changed in place. Doing so would break the applications that depend on the current behavior, and that's most of the Java world talking to PostgreSQL.

So I started a new one: pg-java.

It's a modern, PostgreSQL-specific driver for the JVM, and it is pre-release. But the core driver works, there's a JDBC layer on top of it, and it's been tested far more thoroughly than "pre-release" usually implies.

Why a new driver

Four things drove the design.

PostgreSQL-first. The native API is designed around PostgreSQL's wire protocol and feature set. It is not designed around the lowest common denominator that JDBC has to support across every database on earth. If PostgreSQL can do it, the API should be able to say it directly.

JDBC as a layer, not a foundation. Full JDBC compliance is a long-term goal. There's already a java.sql.* layer that registers a Driver and gives you Connection, PreparedStatement, ResultSet, DatabaseMetaData,

[...]

Hash and sort operations have wildly different relationships with memory, and `hash_mem_multiplier` lets you feed them separately.

Seven major versions of PostgreSQL shipped between 2018 and 2025, one per year without exception, and each with a changelog of 150 to 200 user-visible changes. Each release covers a broad canvas — performance, replication, administration, and security — but every one of them also advanced the SQL layer, filling gaps in the standard, adding missing functionality, or cleaning up long-standing rough edges. Working through the new edition of The Art of PostgreSQL forced me to catalogue them all; this is my selection of the features I kept reaching for while rewriting the examples. I hope it’s useful beyond that context — organized by theme, with the version each feature landed in.

To get a sense of where the community actually puts its effort, Noriyoshi Shinoda of Hewlett-Packard Enterprise Japan has been publishing a meticulous “PostgreSQL New Features with Examples” series for every major release since version 9.4 — each edition catalogues every user-visible change with a working code example. Counting his categories across PG 11–18 gives a clear picture of contributor priorities:

Release	SQL	Performance	Admin & Ops	Replication	Security	Other
PG 11	5	6	5	3

[...]

Picture this: it's Monday morning, your coffee is still warm, and someone from finance slides into your DMs asking why the Q4 revenue number doesn't match what they expected. You know the data flows through about five transformation steps, but the pipeline was built by someone who left two years ago, and the documentation is... let's say aspirational.

So you do what any engineer does: you start digging. You grep through ETL scripts. You trace foreign keys. You find a view that references another view that references a table that might have been renamed at some point. An hour later, you're not sure if you've found the answer or just found more questions.

This is the data lineage problem. And if you've been around data systems long enough, you've lived it.

What even is data lineage?

Let me give you the textbook definition first, then I'll translate it into something that doesn't make your eyes glaze over.

Data lineage is basically a paper trail for your data. It answers:

• Where did this come from? (Provenance - the what and where of your data's origins)

• What else depends on this? (Dependency - the blast radius of a change)

• What happened to it along the way? (Transformation history - the mutations it went through)

• If I change this upstream, what breaks? (Impact analysis - the "oh no" question)

Think of it like a family tree, but for your data. Every value has parents (the data that created it), grandparents (the data that created the parents), and so on back to the original source. And like family trees, it gets complicated fast once you go back more than a couple generations.

Why should you care? (Besides "it's the right thing to do")

Here's where it gets real. Regulations actually require this stuff:

• GDPR Article 5(2) - remember that one? It says people have the right to understand "the logic involved" in processing their data. You can't explain the logic if you can't trace where the data went.

• SOX - if you're in

[...]

PostgreSQL 16 lets servers accept delegated Kerberos credentials to act as users against other services, but it defaults to off because the trade-off is real…

Why Enterprise Platforms Often Fail Long Before They Break

The examples in this article are anonymized, and certain details have been adjusted to protect the organizations involved.

---

The Crossroads Nobody Schedules

Every enterprise platform eventually reaches a crossroads.

Not because it stops working. Because it slowly becomes harder to change.

The warning signs almost never arrive as outages. They arrive as hesitation.

Upgrades get postponed to the next quarter, and then the quarter after that. Deployment windows stretch from two hours to six. Recovery exercises get scheduled, then quietly moved. Architects begin designing around the platform instead of with it — a new service here, a side database there, an integration layer that was only ever meant to be temporary.

And then someone in a design review says the six words that should concern every technology leader:

“Let’s not touch that.”

Nothing appears broken. Availability is excellent. The dashboards are green. Leadership believes the modernization succeeded, and by every metric on the executive dashboard, it did.

Yet confidence has quietly begun to disappear.

Across banking, insurance, telecom, and healthcare, this is how most enterprise platforms actually accumulate risk. Not through catastrophic failure. Through the gradual erosion of trust. The platform doesn’t collapse — it calcifies. And calcification is more expensive than an outage, because an outage ends and calcification compounds.

That observation is what led me to develop the CALM Platform Test.

Not another maturity model. Not another operational checklist. A way of answering a question most organizations never think to ask:

Does this platform become easier to trust as it grows?

That question has become urgent in a way it wasn’t five years ago. We are placing AI workloads — retrieval, embeddings, agents, workflows that take action on behalf of the business — on top of platforms that were never evaluated for their capacity

[...]

The first thing you will probably learn about Postgres, if you follow people who don't like Postgres, is that MVCC is bad. The 40-year-old design mistake. It's signatures are everywhere. Bloated tables that double in size, 32-bit transaction counter limit, the never ending struggle with VACCUM, dead tuples nightmares. It comes with credentials, too: Uber measured the write amplification in 2016 and left for MySQL over it; Andy Pavlo's database group called MVCC the part of PostgreSQL they hate the most. It's a real thing. Postgres is as bad as it gets.

While none of this is exaggerated, it comes down to a real design choice. The bloat, the amplified writes, the vacuum babysitting: every charge traces to a decision, not a defect, and we reproduce each one below on a live PostgreSQL 19 beta2 instance, so you can watch the damage happen yourself. But the verdict that spreads from community to community always stops one question early: compared to what? What does every other engine do instead, and what does that cost?

Because MVCC is not optional. Any database that wants readers to not block writers has to keep multiple versions of rows somewhere, and every engine that does so answers the same four questions:

1. Where do old versions live? In the table itself, or in a separate structure?
2. Which way do version chains point? From old to new, or new to old?
3. What do indexes point at? A physical row location, or a logical key?
4. Who cleans up, and when? A background process later, or the transaction itself?

PostgreSQL's answers: in the table, old to new, physical location, background process later. Every cost the critics list follows from those four answers. And every alternative is a different set of answers with the bill sent to someone else, the writer, the reader of history, tempdb, the cache, the compactor. One of them spent years of engineering to buy the one property PostgreSQL's design has had for free since day one. All of them fail, differently, when a transacti

[...]

PostgreSQL's `gin_fuzzy_search_limit` silently returns a random subset of matching rows instead of all results—a dangerous trade of correctness for speed that…

At a Postgres meetup in Melbourne, I finally got a straight answer to a question that had nagged me for quite a long time: why do people actually choose Postgres? It isn't an idle question for me — I spend my days reading field reports and designing planner features, and keep seeing how much smarter some other databases are. The gap has narrowed drastically over the last ten years, but even now some SQL Server techniques still execute certain queries much faster.

The answer I got was disarming: 'Postgres is just good enough for our purposes.'

Think about what that means. Open source, no vendor lock-in, and you can always find someone who knows the codebase and can reliably fix a problem or scale the load. Good enough beats brilliant. Significant part of database systems market doesn't care about superiority — they want simplicity, maintainability, predictability, and reliability.

That sounds like a trivial observation. It isn't — not if you are the one trying to get a new, pioneering, sometimes provocative feature into Postgres core.

The uncomfortable logic

Postgres holds mission-critical data, so efficiency and scalability are only second- or third-order concerns. And no code is free of bugs: every line you add is a new bug and a maintenance liability the whole community inherits. So the bar is brutal, and it applies in this order — your feature must first prove safety and the absence of regressions, then provide documentation, and only after all that does the gist of the idea finally get to take the stage. A feature survives that gauntlet only if users are already hurting for it: if you can show they genuinely struggle with a problem it solves.

If your instincts were formed between 2000 and 2015, when people boldly shipped massive, breakthrough features, this comes as a revelation. And if you just want an easy commit to prove your database technology, Postgres core is the wrong venue — pick a project where stability matters less, probably something from the OLAP area.

So what do y

[...]

AWS was kind enough to organize an AI workshop this week in Pittsburgh for their employees, and the Postgres committers and core team. The first day covered the basics of setting up Claude and specifically how to use it from the command line to analyze files and automate workflows. We also discussed how AI-automated workflows can do testing, benchmarking, and create proof-of-concept patches to explore ideas that were previously too complex or time consuming to consider.

On the second day, we did hands-on setup of Claude Code, and discussed how we can modify and add things to our source tree to improve AI usage. We also discussed how to improve our workflow in analyzing email threads and reviewing patches. On the final day, we picked various bug reports and used AI to improve email thread analysis and patch review. I found the event very relaxing, like a tech retreat, and hope we can do something like it again.

PostgreSQL's genetic query optimizer has seven knobs, but you should probably only touch one. Learn which one, and why the others are best left alone.

Why PostgreSQL logs entire pages after crashes and why turning it off is riskier than it sounds.

The autovacuum process has been dutifully tending Postgres tables since version 8.1, and almost every release since has acquired some new refinement: smarter thresholds, insert-aware triggering, resource cost limits, and so on. It's the reliable maintenance workhorse that heroically forestalls transaction ID wraparound and keeps statistics fresh. So how did the devs improve it this time around?For most of its life, an autovacuum worker built its list of tables needing attention and then worked through them in roughly the order they appear in the  catalog. Very egalitarian. But a table one transaction away from triggering a wraparound shutdown got the same treatment as a table that crossed a statistical update threshold. Any implied urgency is lost in that context. So how do you teach a maintenance daemon the difference between sweeping the floor and putting out a five-alarm fire? Can an administrator dictate that the cluster cares more about freezing rows than reclaiming space without rewriting the whole scheduler? There's only one way to find out!

Keeping Score

The mechanism behind the change is a prioritization system that scores every table before the worker decides where to start. The launcher picks a database first, favoring any database skirting transaction ID or multixact wraparound, then deferring to whichever went longest without attention. Within that database, the worker builds its candidate list and sorts it by a numeric score instead of catalog order.That score is a weighted heuristic. Postgres computes five separate component scores for each table and keeps the highest as the table's overall priority. The components are the transaction ID age, the multixact ID age, the count of dead tuples waiting to be reclaimed, the count of freshly inserted tuples, and the volume of changes since the last . Whichever of those is highest decides the table's place in line.We don't have to take any of this on faith, because Postgres 19 also exposes a new pg_stat_autovacuum_scores view that reflects the curren[...]

fsync defaults to on and is the most dangerous setting in postgresql.conf—set it wrong and you risk unrecoverable data corruption, not just bad plans.

[...]

Subqueries in FROM clauses get flattened into the outer query by default—but only if the resulting join problem stays small enough.

In my previous blog on the pgEdge Vectorizer and RAG Server, I showed how to build a semantic search pipeline using dense vector embeddings. The RAG Server already did hybrid search, combining vector similarity with BM25 keyword matching, but BM25 was handled at the application layer, not inside PostgreSQL.That changes now. The pgedge-vectorizer extension adds BM25 sparse vector generation directly into the vectorizer, running inside PostgreSQL alongside the dense embeddings. Results are fused using reciprocal rank fusion (RRF). In this blog I will show you what this means in practice.I am using the same Rocky Linux ARM64 VM and testdb configuration from the previous blog: two pgEdge nodes, n1 on port 5432 and n2 on port 5433, using Ollama with nomic-embed-text. If you have not read that blog yet, start there first.

Why Hybrid Search?

To understand what this feature does, it helps to understand the three pieces behind it.

Dense Vector Search

When you run a semantic search, the extension converts your query and data into a list of numbers called a vector. These numbers capture meaning. Data that matches your query ends up with similar numbers, even if the words are completely different.That is why a query like "how do I get back into my account?" finds an article titled "Account Recovery" even though the query uses none of the same phrasing. The embedding model understands that getting back into your account and account recovery describe the same thing.Dense search is powerful for conceptual queries. Where it struggles is exact technical terms. Search for "wal_level = logical" and the model may rank a general replication article above the one that specifically explains that parameter, because it treats all replication content as semantically similar.

BM25

BM25 takes the opposite approach. It does not understand the meaning at all. It counts words.Specifically it scores documents based on two things: how often your query terms appear in a document, and how rare those terms are across your entire knowle[...]

file_extend_method is an escape hatch wearing the costume of a tuning knob. It exists for one purpose: to let you turn off a PostgreSQL 16 optimization on the filesystems where that optimization turned out to misbehave. When a table grows, PostgreSQL has to extend its data file, and there are two…

Building the OAPE PostgreSQL Certification

I’m one of the founders of the Open Alliance for PostgreSQL Education (OAPE).

Over the past two years, I’ve had a front-row seat to watching an idea become a community, and a community become a movement.

This is the story of how the idea of an open, vendor-neutral PostgreSQL certification turned into an organisation supported by contributors from around the world.

The classic “What If” — thought

There are moments when an idea seems so obvious that you wonder why it doesn’t already exist. Then you start digging into the details and realise why nobody has built it yet.

In spring 2024, I was sitting over a coffee with Jan Karremans. Nothing unusual. But this time, our conversation about PostgreSQL drifted towards certifications.

There was one question hanging in the air and dominating the conversation: “There is no independent PostgreSQL certification available — right?”

And it led to another: “What would it take to build one?” (a classic “What If”-question :D)

At the time, I hadn’t contributed much to the PostgreSQL community. Coming from the corporate world, I was still learning how open source works. Companies have budgets, dedicated teams, project plans, and management. Community initiatives are different. They exist because people decide something is worth building and over time, I learned something that now seems obvious: community projects don’t simply appear. They exist because people invest their evenings, weekends, and energy into creating something that benefits other people.

2024 was a real eye-opener for me as. Somewhere along the way, I realised I had become emotionally invested in the community. It started to feel a little like looking after an extended family.

Looking back, that coffee marked the beginning of a very interesting journey.

Open source projects start with people

Ideas are easy. Finding the right people to turn an idea into reality is much harder.

A few months later, Jan and I met Di

[...]

Postgres Summit US 2026 (formerly: PGConf NYC) will take place September 30 - October 2, at Convene, in New York. EDB is joining the event as a sponsor at the Gold-level. Our team of Postgres experts, core contributors, and innovators have secured a stellar lineup of sessions through the Call for Papers. From cloud-native transformations to deep-dive database internals, we’re covering a wide range of topics. 

Here is a sneak peek of what EDB is bringing to the stage in NYC.

Strategy & Architecture

Postgres adds roughly 200 features and improvements every year, yet a few major milestones remain

On 15 July 2026, the Prairie Postgres Meetup Group met, organized by Henrietta Dombrovskaya and Carlos Aranibar.

Speakers:

• Zach Paden
• Anna Bailliekova

On 18 July 2026, Alicja Kucharczyk, Pavlo Golub, Denys Holub & Anastasia Golub staffed the PostgreSQL booth at WAWTech Summer.

The PostgreSQL Madagascar Conference 2026 took place on 18 July 2026.

Organizers:

• BAOVOLA Marie Anna
• Dominique RAKOTONIRINA
• RAVAKINIAINA Tokifanantenana

Program Committee:

• Bodo Arivola
• Jerson Raheriniaina
• Toky Fandresena MANOVOSOA
• Vahatra

Speakers:

• Fabian Kimambo
• Lova Andriarimalala
• damien clochard
• Hans-Juergen Schoenig
• Nicaise CHOUNGMO FOFACK
• Prafulla Ranadive

Claire Giordano and Aaron Wislang hosted and published a new podcast episode on 17 July, 2026 “Working on Postgres after 13 years on SQL Server with Panagiotis Antonopoulos from the Talking Postgres series.

On 8 July, Evangeline Cheng delivered a talk at the PUG NYC, organized by Miaolai Zhou and Mason Sharp

Community Blog Posts:

• Jimmy Angelakos about PostgresEDI July 2026 Meetup — Public Speaking, AI Compliance
• Henrietta Dombrovskaya about Prairie Postgres July Meetup: Proudly Sourced at Midwest!
• Monica Oyugi about PGConf.dev 2026: Vancouver Showed Up and So Did I

Time, Physics, Mathematics, and Databases

Physics treats time as one of the fundamental dimensions of the universe. Mathematics transforms time into measurable values, equations, intervals, and limits. Databases quietly preserve time as operational reality. Every login, transaction, API call, backup, audit event, financial transfer, and monitoring alert depends on accurate timestamps. Modern computing runs on time far more than most people realize. 

A cloud-native application serving millions of users every day continuously tracks:

• login sessions,
• token expiry,
• replication timelines,
• backup retention, 
• audit histories,
• scheduled jobs,
• distributed events,
• cache expiration,
• monitoring alerts,
• certificate validation etc.,

Every one of these operations depends on timestamps behaving correctly. Most developers never think deeply about timestamps because modern systems usually make time feel invisible. A timestamp appears as a simple date in logs or dashboards. Underneath that simplicity, operating systems and databases continuously calculate time mathematically.

Many Unix-like systems calculate time as the number of seconds passed since:

1 January 1970

00:00:00 UTC

This reference point became known as the Unix Epoch.

At the time, this design looked practical, elegant, and efficient. Nobody expected that decades later engineers would still discuss the consequences of that decision while running AI workloads, distributed systems, Kubernetes clusters, and global cloud infrastructure.

The Integer That Quietly Controls Time

The Year 2038 problem begins with a mathematical limitation. For years, many systems stored timestamps using signed 32 bit integers. Signed integers can store both positive and negative numbers, but they also have a fixed range.

A signed 32 bit integer can store values from:

-2147483648 to 2147483647

The maximum positive value becomes extremely important because Unix-like systems count time forward

[...]

PostgreSQL 18's `file_copy_method = clone` can copy a terabyte database in half a second on copy-on-write filesystems. Here's when and why you should use it.

With UPDATE/DELETE FOR PORTION OF looking like it will land in Postgres 19, I’ve been thinking about next steps. I read a very helpful paper on temporal relational algebra last May by Richard Snodgrass. Here are some notes on it.

The paper was “An Overview of TQuel”. It’s Chapter 6 in Temporal Databases: Theory, Design, and Implementation from 1993.

TQuel was an extension to Quel, the query language for Ingres. Ingres, of course, was the predecessor to Postgres!

My main motivation reading this paper was to learn more about the algebraic identities of temporal relational operators. A query planner depends on such identities to transform your query into a more efficient shape. For instance, if you can filter rows before joining tables instead of after, you’ll get a much faster execution. The useful identities for regular relational operators are well-known, but what about temporal operators? If we ever want to support temporal joins and setops in Postgres, we have to figure that out.

I implemented some temporal operators in SQL in my temporal_ops extension. Since they are just SQL, I don’t have to worry about optimizer correctness. But it would be better to have dedicated executor nodes. That should get us closer to an optimal implementation. I want to teach that extension to inject CustomScans . . . somehow . . . maybe with a post-parser hook? Once I have that, I can experiment with planner transformations.

But as a first step, I’m trying to see what is in the research already. One surprise in Snodgrass’s paper was that TQuel valid-times are not intervals (like Postgres rangetypes or SQL:2011 PERIODs). Instead they are sets of “chronons”: all the times that the tuple is true, whether contiguous or not. I can see how that might be a more “pure” representation. There is something artificial to forcing the valid-time to be only a single contiguous stretch of time. Fortunately a set of chronons is exactly a multirange, so it is still something you could represent in Postgres.

A bigger surpri

[...]

The PostGIS Team is pleased to release PostGIS 3.7.0beta1! Best Served with PostgreSQL 19 Beta2 and GEOS 3.15.0beta2.

This version requires PostgreSQL 14 - 19beta2, GEOS 3.10 or higher, and Proj 6.1+. To take advantage of all features, GEOS 3.15+ is needed. To take advantage of all SFCGAL features SFCGAL 2.3.0+ is needed.

This release contains fixes and enhancements since 3.7.0alpha1 release.

• source download md5

• NEWS

• HTML Online en ja zh_Hans fr

• PDF docs: en ja, zh_Hans, fr

• Cheat Sheets:

  • postgis: en ja zh_Hans fr
  • postgis_raster: en ja zh_Hans fr
  • postgis_topology: en ja zh_Hans fr
  • postgis_sfcgal: en ja zh_Hans fr

This release is an alpha of a major release, it includes bug fixes since PostGIS 3.7.4 and new features.

Changing a PostgreSQL backup solution involves much more than installing a new binary. Backup repositories, retention policies, recovery procedures, operational runbooks, and compliance requirements have all been built over time. Any migration needs to fit into that operational landscape while preserving confidence in recovery. That thinking shaped the migration approach behind pg_hardstorage.

Built around Operational Continuity

Every PostgreSQL environment has its own operational requirements, infrastructure, and retention policies. The migration guides were written with that in mind. pg_hardstorage approaches migration as a gradual operational transition. 

• Existing repositories remain in place while new backups are written into a new pg_hardstorage repository. 
• Historical backups continue to be restored using the tool that created them, allowing organizations to retire previous repositories according to their existing retention policies and operational timelines.

This approach avoids repository rewrites and gives teams the opportunity to validate recovery before completing the transition.

A Migration model designed for PostgreSQL Operations

The migration guides follow the same operational model across supported backup solutions. A new pg_hardstorage repository is introduced alongside the existing environment. A fresh full backup establishes the new backup history, WAL continues to be captured during the transition, restores are verified before production cutover, and the existing repository remains available until its retention window naturally comes to an end.

For supported backup tools, compatibility shims help preserve existing automation by allowing familiar commands and scheduled jobs to continue producing native pg_hardstorage backups. 

Combined with the dual-write migration model, teams can evaluate the new environment, validate recovery procedures, and choose a cutover point that fits their own operational schedule.

Migration Guides

Every migration guid

[...]

extra_float_digits is the setting whose job changed out from under it. For most of PostgreSQL’s history it forced a choice between floating-point output that was easy to read and output that was exactly right, and you could not have both. Since PostgreSQL 12 you no longer have to choose, which is…

On July 15, we hosted the second meetup at our new location, the Chicago Innovations Center. The CIC is evolving, and we like it more and more! I will probably stop saying it at some point, but for now, I want to repeat it one more time: we hope it will be our permanent home!

We keep experimenting to better serve our community and work toward our mission of supporting Postgres education. For the longest time, I was reluctant to switch to the “two talks at one meetup” model. We used to have two talks in 2016-2017, but ended up switching to one talk per meetup. My rationale was to be able to have a really deep dive into a topic we were discussing, but let’s admit it: listening to a long (even very well-presented) talk after a full workday in the middle of the workweek and staying focused is challenging :)).

This time, we had two shorter talks, both very practical and very engaging. Zach Paden from Symetra presented Declarative schema management with pgschema, and Anna Bailliekova presented PostGIS Quick Start.

I really enjoyed both talks! In Zach’s presentation, I liked the clear explanation of why the declarative, Postgres-native, way of writing migrations eliminates multiple problems (“just use Postgres” approach). And I liked Anna’s presentation because, as she rightly mentioned afterward, people are often afraid to use PostGIS because it feels complicated, and at the same time are reluctant to admit they do not know how to use it. QuickStart was a perfect format!

I also wanted to talk about one more important change which wouldn’t be possible without the support of Chicago Innovations: we now have childcare for the duration of the meetup! I can’t tell you enough how thankful we are for the CIC for recognizing the importance of childcare in providing access to professional development for everyone.

The current childcare space is temporary; there will be a bigger and better-equipped room in the near future. Still, even now, we are happy to offer this

[...]