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

[...]

I wonder what we can confidently say about how AI is changing the way our community works.

My hunch is that, as usual, we are held captive by our own experience and use AI in the ways we're accustomed to. Text chat, for example, remains the primary way of interacting with AI in software development — even though voice commands are often quite sufficient, and the necessity of a keyboard is no longer all that obvious. It's also unclear what will happen to websites and other digital interfaces: picking out a bike or a laptop is clearly easier in a chat with an AI assistant, and for the purchase itself, a banking app will do.

Yet some fundamental shifts can already be glimpsed. To my mind, the two most significant are the growing role of public sources of information and the shift of human effort away from processing and presenting information toward producing new knowledge.

Openness as a condition of existence

People now include AI in their decision-making chain, in various forms. Even in the most conservative variant (like PostgreSQL core development), it is present as a mechanism of critique — hunting for weak spots in a nearly finished product. But if a relevant source of information is not openly accessible, an LLM simply doesn't know about it. Which means it won't use it in decisions, won't combine it with other sources, and won’t check it for correctness. For the model, such knowledge does not exist.

Imagine: with limited time and money, you present your breakthrough idea not at a top international conference but at a university seminar in your hometown. Or at a department meeting, even. Twenty years ago, it would simply have sunk without a trace. Today, when I ask an AI agent to analyse a problem and identify known attempts to solve it, it draws on two sources of knowledge: whatever was available during training and whatever it finds by searching the web. So what matters is no longer so much where your results are published as the mere fact of their presence online, their accessibility

[...]

Write a second PID file to a custom location—useful when your cluster manager expects PostgreSQL's PID at a specific path like `/run/postgresql/postgresql.pid`.

PostgreSQL 18 lets you store extensions anywhere with `extension_control_path`, ending the requirement to install them into the system directory.

Postgres 19 is just a smorgasbord of new functionality; it's genuinely hard to believe they packed all these new features into a single release. To that laundry-list of new capabilities, it adds something I almost missed. We all know and love the Postgres Write Ahead Log (WAL), where all writes begin their lives. I even recently wrote about how the background checkpoint system can overwhelm storage when not properly tuned.What about the times when a DBA wants to purposefully invoke a manual CHECKPOINT to flush any pending writes to the heap? Just one quick command and Postgres invokes an immediate flush, then returns control once the dust settles. Until Postgres 19, that was the entire interface. . It's like a Zen koan.It turns out there were a few tricks we could teach this old dog.

A Blunt Instrument

A bare  means "reconcile everything immediately, and don't come back until it's done." There are a few obvious scenarios where DBAs may execute this kind of targeted checkpoint:

• Before taking a backup so the base image starts from a known-good state.

• Prior to a
• pg_upgrade
•  so the old cluster is fully settled.

• Between benchmark passes so each run starts from the same clean slate. We even leverage that approach several times in this very article.

In every one of those cases, "as fast as possible" is precisely the intent. Given that only superusers or members of the pg_checkpoint predefined role can use it, that seems about right.The trouble is that its single behavior was also its only behavior. When the only tool you have is a hammer, everything becomes a nail. As we learned from the write storm article, sometimes a full and immediate flush is the last thing a busy server needs. If our  means the next checkpoint won't happen for a while, maybe there needs to be an option to start the process early.And now with Postgres 19, there is.

A Challenger Appears

Improvements to the  command in Postgres 19 came in three stages. The first added nothing user-visible at all. It simply taug[...]

PostgreSQL's `exit_on_error` GUC promotes every error to a session-terminating event—but this fail-fast illusion masks a destructive truth.

Spock 6 has landed in Beta. pgEdge's multi-master replication extension now runs on PostgreSQL 16, 17, 18, and 19, tracks replication progress in shared memory instead of a catalog table, spills oversized replay queues to disk, and reports conflict statistics per subscription. Spock 5 was already doing the hard work of multi-master replication in production. Spock 6 makes the same engine faster, easier to watch, and considerably harder to kill.We are currently finalizing internal testing, as well as ensuring Spock 6 support is fully available in the Control Plane, HELM, and Cloud, so any feedback as we march towards GA is greatly appreciated.

Rearchitected Internals

Spock 6 ships a custom WAL resource manager (RMGR), and moves progress tracking from a catalog table into shared memory.In a multi-master cluster, every subscriber tracks which transactions it has received and applied from each peer. Previous versions stored this progress in the spock.progress catalog table, so every replicated transaction generated an additional catalog write. Under light workloads that's fine. Under heavy replication traffic across a busy multi-node cluster, those writes create contention and the progress table accumulates bloat that needs periodic maintenance.Spock 6 tears the catalog write out of the hot path. Progress state now lives in shared memory during normal operation and is snapshotted to $PGDATA/spock/resource.dat on clean shutdown — nothing extra is written per transaction. Durability comes from PostgreSQL's replication origin tracking, which already records the last commit applied from each peer: after a crash, Spock reconciles its state against the origins, the same machinery PostgreSQL's own logical replication relies on. The custom resource manager complements this by writing a snapshot of the progress state into the WAL at shutdown and during node operations, so replication state is inspectable with standard tools like pg_waldump, in the same durable log PostgreSQL trusts for its own recovery. The old spock.p[...]

Postgres 19 is planning to change the default TOAST compression from pglz to LZ4, so let's look at how Postgres compresses data in table storage and indexes. Postgres uses a single, unified compression framework for table (heap), TOAST, and indexes. In heap and TOAST, compression is automatic and on by default for variable-length types like TEXT, VARCHAR, BYTEA, and JSONB. In indexes, it is opportunistic: compression fires only when an individual key exceeds the size threshold, not for every variable-length value stored in an index.

click to expand

History of Postgres Compression

Compression was first added in Postgres 7.0, released in 2000, but not in the form it takes today. At the time, Postgres had a strict 8kB maximum row size, and trying to insert more than 8kB would throw an error. Fixing this row size limit was a priority for the Postgres core team.

The first attempt to work around the limit was an explicitly compressed field. Postgres 7.0 shipped an lztext data type that used the pglz compression algorithm. This implementation had tradeoffs: the 8kB row limit still existed, and users had to explicitly choose a compressed data type.

After the 7.0 release, the next logical step might have been to add more compressed data types like LONG or BLOB (as many closed source databases were doing at the time). Instead, the Postgres core team rejected additional data types and rallied around TOAST. Discussions on the pgsql-hackers mailing list show the group split the 8kB problem into two distinct problems: a data type problem and a physical storage problem. Compression and TOAST were the answer to the physical storage problem.

TOAST with pglz

With Postgres 7.1, TOAST was implemented using pglz.

The pglz algorithm lives in the pg_lzcompress.c file. Because Postgres is open source, we can read the author's reasoning for home-rolling a compression algorithm right in the comments:

• Trade ratio for speed: pglz is fast to compress and decompress, and willingly gives up compress

[...]

[...]

Six months ago we started writing the PostgreSQL backup tool we kept wishing existed. Now pg_hardstorage has shipped, and you can read every line of it on GitHub before you trust it with your WAL stream.

Why another backup tool?

At CYBERTEC we have spent more than two decades helping organisations run PostgreSQL in production. The single most consistent thread through all of those engagements is the same one: backups are the load-bearing wall of a database. When they hold, you forget about them; when they don't, nothing else matters.

Which is why we believe the PostgreSQL ecosystem is healthier when there is more than one serious open-source backup option, and when none of those options depends on the goodwill of a single maintainer or a single company. Choice is a feature. A migration path between tools is a feature. Knowing you can switch without rewriting your recovery plan is a feature.

pg_hardstorage exists to add another credible option to that pool. It has been in real customer deployments for over a year, we wanted to be sure the wire format and the operational shape were right before asking anyone else to depend on it. Today it goes open-source under Apache 2.0, with no enterprise edition and no CLA.

The existing tools: pgBackRest, Barman, WAL-G are excellent pieces of engineering, and the work behind them is a large part of why the PostgreSQL backup story is as mature as it is today. We have enormous respect for the people who build and maintain them. pg_hardstorage is not trying to displace any of them; it is trying to give operators a credible alternative when their requirements pull in a different direction, and to give them a smooth way across if they ever need to take it.

That direction, for us, is the next generation of how PostgreSQL is actually deployed:

• Cloud-native by default. The data plane is the PostgreSQL replication protocol over a normal libpq connection — the same one a streaming replica uses. That single architectural choice is the entire reason pg_h

[...]

Event triggers fire on DDL and login events, not rows—and a buggy one can lock out every user, even superusers.