Latest Blog Posts

Open-source Citus delivers millions of queries per second more efficiently than Neki, the only other published data point at this scale

Last month PlanetScale published a blog post on how they achieved 118 million queries per second on Neki, their sharded Postgres. It included data points at 5, 50 and 512 shards, and showed the scalability between them.

While this was breaking news, our team at StackGres was working on a benchmark to show how we removed Citus' single-coordinator ceiling, allowing Citus to scale without limits. We introduced an architecture in StackGres 1.19 that allows to create as many Query Routers (think of Citus Coordinators, but you can scale them out) as you need. Query Routers scaled near-linearly up to two routers, allowing a three worker cluster to go from 550K queries per second with a single coordinator to 1.4M with three Query Routers.

The question then became obvious: can we compare Neki and Citus? Can Citus match, or outperform, with the new Query Routers, Neki? One observation further motivated us: Neki’s numbers show that data nodes were delivering 231K tps. A trained eye would soon recognize that figure as a low per node number for a modern ARM64 server with 64 cores. Certainly there’s overhead on a sharded system, and both Neki and Citus suffer from it. But we believed Citus could do better.

And so it did. We matched the 1M and 10M data points. At those data points Citus was able to achieve slightly better performance (with possibly lower latency too, but those numbers were not drilled down in Neki’s post) with 60% and 48% of the data nodes, respectively. The number of Query Routers was half of Neki’s at 1M and the same at 10M. Overall, Neki needed 1.5 to 1.8 times the vCPU to reach Citus performance levels.

Our benchmark was created as similar as possible to Neki’s, but they haven’t published all the details about their setup. Our benchmark setup, but also all the code needed to reproduce it anywhere, will be published soon as a follow-up blog post, so th

[...]

[...]

The 2026 version of the Ruby on Rails Community Survey results are now live.

Two things caught my eye: just how much PostgreSQL is in production for Rails apps, and the learning resources Rails developers use.

The survey has responses from nearly 1,800 developers.

Among relational SQL databases, 84% of respondents use PostgreSQL in production. That’s wild! The next one is MySQL at 23%.

84% of nearly 1,800 surveyed Ruby on Rails developers use PostgreSQL in production

This reflects a multi-year trend not only in the Ruby on Rails community but also in the broader industry among relational databases.

According to the DB-Engines Ranking Trend, Oracle, MySQL, and Microsoft SQL Server are all still more popular than PostgreSQL, but declining. In the graph below we can see the growing popularity of PostgreSQL and this trend line implies it may surpass Microsoft SQL Server. MySQL could be next.

Popularity of Oracle, MySQL, Microsoft SQL Server and PostgreSQL per DB-Engines

How do Rails developers learn?

How do developers learn? Books hold a smaller but steady percentage among learning resources. 37% of respondents in their first two years of learning felt reading whole books was most helpful, while 10% have read parts of a book and found that best.

What worked best among respondents was building and deploying their own applications. This makes sense! That’s how it’s always been for me too, nothing beats building something yourself and becoming an owner and operator. Documentation, learning videos, podcasts, books, and blog posts all help support developers looking to improve their skills.

High Performance PostgreSQL for Rails Ranked #12

I was happy to see High Performance Pos

[...]

My job at pgEdge allows me a significant amount of time to work on pgAdmin, a project I started nearly 30 years ago. The previous blog and this followup is an update on some of the recent work I’ve been doing.In my last post I wrote about moving pgAdmin's build farm from Jenkins to GitHub Actions, and I promised a follow-up about , which is the least famous repository in the pgAdmin organisation and quietly one of the most important. If you have installed pgAdmin on Windows in the last year or so, or on macOS since the move to GitHub Actions, you ran code that came from the buildfarm.

What pgbuild is for

pgAdmin's desktop packages are self-contained, because that is what people expect on Windows and macOS: you download an installer or a disk image, you run it, and pgAdmin works, without you first having to install PostgreSQL's client libraries, a Kerberos implementation and an SSL library, and without pgAdmin quietly binding itself to whatever versions happen to be on your machine. That convenience has to come from somewhere, and where it comes from is , which compiles PostgreSQL itself along with OpenSSL, Kerberos, , , ICU, , , ,  and a handful of build tools, for Windows on x86_64 and for macOS on both Intel and Apple silicon, and publishes each as an archive that the pgAdmin build then downloads and links against.It grew out of a repository called , which as the name suggests did this only for Windows, and which itself came out of conversations at PGConf.dev 2025 in Montreal, with Dave Cramer and Andrew Dunstan amongst others, about how useful it would be to have a standardised reference build of PostgreSQL and its dependencies for Windows: something that anybody shipping a PostgreSQL client on that platform could build against, rather than every project solving the same problem privately and slightly differently. The macOS dependencies, meanwhile, were built on the Jenkins farm right up until the migration, by a separate set of jobs with their own conventions, so bringing them into the same repository [...]

Some time ago I read this blogpost. They wrote about logging changes to table using a trigger, but one thing that caught my attention was: Storing only the changed columns made the log five times smaller and the trigger slower. Figured I can try it myself… Unfortunately they didn't provide schema of table, nor test … Continue reading "Old tech is sometimes better – a case study based on blogpost from Now-Next…"

Prairie Postgres just turned two! We say “community building” often, maybe not always thinking about what it means, but looking back on the past two years, I can confidently say the most important achievement, the one I’m most proud of, is reshaping the Chicago Postgres Community.

Gradually, our gatherings transformed from a group of experienced DBAs plus a dozen newcomers who sat quietly and didn’t ask any questions because they didn’t know where to start, to a gathering of curious developers, data scientists, and yes, both junior and experienced DBAs are here – how could we keep going without them? Each talk sparks a lot of questions; people stay engaged in conversations long after it ends. It’s not just about “Do you have job openings in your organization?” It’s also (and mostly) about knowledge sharing, talking about passion projects, and building connections.

I am not saying it happened during these last two years; things started to change a while ago, but the changes were empowered by the sense of ownership: it’s our organization, our meetups, and it’s up to us to make the most of them.

Another exciting change is the growth of our connections with other technical meetups. We have strong ties with Chicago Code&Coffee and the Chicago Ruby and Django communities, and we are planning our first joint meetup with ChiPy. We are also exploring ways to strengthen connections with the Chicago AWS meetup and the Databricks meetup.

Working together. Building connections. Building community. All I was dreaming about

What am I looking forward to? What would I like us to achieve in our third year?

First, the geography. There is more Postgres in the greater Midwest than just Chicago, and Prairie Postgres is happy to help give it a jump start. Reach out to us – you know where we are!

Second, building connections with educational institutions. So far, there is nothing major to report, except that we have some students coming to our meetups, but we hope we can do more.

Finally, we hope to b

[...]

Configure a replication slot name on your standby and the upstream keeps WAL forever—until the slot itself fills your disk or the standby dies holding an old… (I consult on PostgreSQL through PGX Inc..)

We’re continuing our review of the March CommitFest for PostgreSQL 19. This second article in the series covers the changes related to our DBA1 and DBA2 courses.

As a reminder, here’s the plan for our coverage of the final PostgreSQL 19 CommitFest:

Part 5.1 (QPT)

Part 5.2 (DBA1, DBA2) -- you are here 🙂

Part 5.3 (DBA3, DBS)

Part 5.4 (SQL, DEV1, DEV2)

For the earlier CommitFests, see: 2025-07, 2025-09, 2025-11, 2026-01.

Here’s what’s covered:

• REPACK: rewriting a table to reclaim disk space
• Autovacuum: table processing order
• Autovacuum: parallel index vacuuming
• Enhanced transaction ID wraparound warnings
• Checkpoint reason in the completion log message
• Less WAL and on-access visibility map updates
• More code paths use read streams
• pg_stat_lock: statistics on long lock waits
• pg_upgrade: faster large object transfer, part 2
• oid2name: file paths relative to PGDATA
• psql: comments on internal queries
• log_min_messages per backend type
• Stats reset time for pg_stat_database_conflicts and pg_statio_all_sequences

...

Build Your PostgreSQL RBAC Lab

Understanding PostgreSQL roles and privileges becomes much easier when you see them in action.

Instead of simply memorizing GRANT and REVOKE commands, we’ll build a small credit-card application environment and explore how PostgreSQL manages users, object ownership, and access permissions.

What will you learn?

Through this hands-on lab, we’ll explore:

• Roles and Users — Understand LOGIN, NOLOGIN, and why PostgreSQL treats users and groups as roles.
• Object Ownership — Discover how a NOLOGIN role can own databases, schemas, and tables.
• Privileges and Access Control — Learn how database, schema, and table permissions work together.
• Role Membership — Understand INHERIT, SET ROLE, and how privileges flow between roles.
• Least-Privilege Security — Build separate read-only and read-write access for application and reporting users.
• Default Privileges — Automatically configure access for future database objects.

[...]

Álvaro Herrera will be joining us in November to discuss, when our monthly hacking workshop will cover Table repacking, done right. If you're interesting in joining us, please sign up using this form and I will send you an invite to one of the sessions.Read more »

Sooner or later, someone on the team reads about write skew. It is an unsettling read: two transactions, each correct on its own, each looking at data the other is about to change, both committing, and the database ending up in a state that no ordering of the two could have produced. READ COMMITT… (I consult on PostgreSQL through PGX Inc..)

For most of the last decade, every copy of pgAdmin that anyone has ever downloaded was built by a Jenkins server, and for most of that time it did the job perfectly well. It built the Debian and Red Hat packages, the Windows installer, the macOS app bundle, the Python wheel, the container image, the Helm chart and the documentation; it signed them, published them to the download site, and told me when something had gone wrong. It was also, and there is no polite way to put this, a machine (and a bunch of worker machines) that almost nobody could see, running jobs configured through a web interface whose settings existed nowhere else. A handful of us could log into it and push a release, although in practice I was the one who knew how it was wired together and therefore the one who fixed it when it broke, which is its own kind of single point of failure. If you contributed a change to pgAdmin's packaging, you could not read the thing that would build it, and if I had been hit by the proverbial bus, the recovery plan involved somebody logging into a server and reading XML.We have now moved the whole lot to GitHub Actions, and since this changes things for both users and contributors, it seems worth explaining what has changed and why.

Why move at all

The honest answer is that the build farm had become the least visible part of the project. pgAdmin's source code is reviewed, discussed and version controlled; its build process was none of those things. A Jenkins job is a configuration in a database, and whilst we did eventually keep that configuration in a repository, the repository was a backup rather than the source of truth: the running system was authoritative, and a change made in the interface was live immediately, reviewed by nobody.That matters more than it sounds. The packaging is where a surprising number of user-visible bugs live, because it decides which libraries get bundled, which Python interpreter ships, how the installer is signed, and where the packages land in the repositories that  and  rea[...]

2026년 11월 17~18일 홍콩에서 열리는 PGConf.Asia 2026에서 EDB 전문가들이 PostgreSQL의 주요 기술과 운영 과제를 소개합니다. AI 기반 SQL 생성과 검색·RAG부터 스케일아웃 아키텍처, 성능 튜닝, CloudNativePG 및 TPA 기반 클러스터 관리까지 주요 발표 세션을 미리 살펴보세요.

`primary_conninfo` tells a standby where to stream WAL from—but only after the archive and pg_wal run dry. (I consult on PostgreSQL through PGX Inc..)

I packaged bigquery_fdw over 6 years ago. However if you tried to use bigquery_fdw from the PostgreSQL YUM or zypper repositories recently, there is a good chance it did not work: the Python modules it needs could not be imported by the interpreter it runs in. The packages that are in the repositories as of today fix that on RHEL 8, 9 and 10, Fedora 43, 44 and 45, Amazon Linux 2023, and SLES 15 and 16. This post explains what was wrong, what changed, and what (if anything) you need to do.

The full history is in issue #367.

Continue reading "bigquery_fdw works again on every distribution we ship in the RPM repo"

Debugging PostgreSQL connections requires stopping a backend before it does anything interesting. (I consult on PostgreSQL through PGX Inc..)

We’re wrapping up our series of articles reviewing the changes in PostgreSQL 19. The previous articles covered the first four CommitFests: 2025-07, 2025-09, 2025-11, 2026-01.

Today we begin our review of the March 2026 CommitFest. Why «begin»? As in previous years, the March review is going to be a long one: the final CommitFest of the cycle is where many of the most important changes land. Such a review is hard not only to write but also to read all the way through 🙂. That’s why this time it’s split into four articles.

The first article covers everything related to query optimization, in other words, the topics of our QPT training course. The second will focus on changes more relevant to the DBA1 and DBA2 courses. The third will cover DBA3 and DBS. The fourth will look at new SQL features, as well as changes related to the DEV1 and DEV2 courses.

RevertFest

But first, let’s look at what won’t make it into version 19. An impressive number of features were committed to version 19 before the feature freeze, only to be reverted before the release:

• Partitioning: merging and splitting partitions (3e8bcc864)
• GROUP BY ALL (a32733d8f10)
• pg_dumpall: support for all pg_dump output formats (7ca548f23a6)
• SQL Property Graph Queries (SQL/PGQ) (b1f106c80)
• SQL:2011 Application Time Update & Delete (a4b26b8f7)
• Built-in functions that return the DDL for creating roles, databases, and tablespaces (db169985c)
• Enabling/disabling data checksums without shutting down the cluster (c05d5ce12)

At the time of writing, not all open items have been resolved, and the release is tentatively scheduled for October 29. So the list of new features may shrink further.

CommitFest

With that caveat in mind, let’s move on to the changes related to query optimization. Here’s what’s covered:

• Query plan stabilization and plan advice
• auto_explain: logging EXPLAIN options added by extensions
• EXPLAIN (analyze, timing): reducing timing overhead

[...]

[...]

This is part 3 of a series about Postgres logical replication use-cases, and about how the feature set has evolved over the past ten years and ten releases (Postgres 10 through the Postgres 19 beta), one architecture at a time. Part 1 built a hub-and-workers system for write scalability and has the table of what each release added, which this post assumes. Part 2 consolidated several application databases into one warehouse. This one is the most common reason to touch logical replication at all: a major-version upgrade with no downtime, and a way back if it goes wrong.

How ctid-aware segment partitioning, an inverted DocId map, and bitmap postings accelerated ParadeDB's Wikipedia COUNT queries—then a look at the rest of search, where ParadeDB delivered 10–22x TIN's throughput on filtered and time-sorted Hacker News queries.

PGConf Asia 2026 is heading to Hong Kong from November 17–18! As a premier regional event for the PostgreSQL community, PGConf.Asia brings together developers, contributors, DBAs, and enterprise users from across the continent. Several EDB team members will be presenting sessions this year. Additionally, EDB's own Bruce Momjian is serving on the organizing committee and co-chairing the program committee. Here is a sneak peek at the EDB-led sessions at PGConf Asia:

Strategic insights

What's Missing in Postgres? - Bruce Momjian (Keynote)

While Postgres introduces roughly 200 features and

PGConf Asia 2026 is heading to Hong Kong from November 17–18! As a premier regional event for the PostgreSQL community, PGConf.Asia brings together developers, contributors, DBAs, and enterprise users from across the continent. Several EDB team members will be presenting sessions this year. Additionally, EDB's own Bruce Momjian is serving on the organizing committee and co-chairing the program committee. Here is a sneak peek at the EDB-led sessions at PGConf Asia:

Strategic insights

What's Missing in Postgres? - Bruce Momjian (Keynote)

While Postgres introduces roughly 200 features and

Do you know about the Winklevoss twins, Cameron and Tyler? They grew up together, went to the same university, and eventually built very different things around technology, finance, and entrepreneurship. Whatever you think of their story, there is something fascinating about twins who start from the same place and then take their abilities into different directions.

Now imagine two twins who grow up in completely different families.

One becomes obsessed with organizing information, while the other becomes obsessed with doing enormous amounts of work at the same time.

They spend years in completely different worlds. Then one day, they meet. And someone says:

“You two might actually work really well together.”

That is the story I want to tell about PostgreSQL and CUDA.

They are not really twins, of course. They were born almost a decade apart, built for different purposes, and live at very different levels of the computing stack.

But there is an uncanny similarity in one of the ideas behind them. 

Let me explain.

Two births, roughly a decade apart

PostgreSQL's story goes back to the POSTGRES project at the University of California, Berkeley. In 1996, the project moved from the name Postgres95 to PostgreSQL, starting with version 6.0.

Then, roughly ten years later, another important piece of the computing world arrived.

In 2006, NVIDIA introduced CUDA, giving developers a programming model for using GPUs for general-purpose computation.

Two technologies with very different beginnings. Relational databases like PostgreSQL have been dealing with something, humans have been struggling with forever:

How do you keep information organized and reliable when lots of people are using it at the same time?

CUDA came from a very different question:

What if we could use the enormous number of computing resources inside a GPU for things other than drawing pixels?

Different questions with different answers.

But there is a common idea hiding underneath both.

[...]

The `port` parameter does double duty: it names the TCP socket and the Unix socket file too. (I consult on PostgreSQL through PGX Inc..)

Three ways to create a read-only user in PostgreSQL 17, measured: what each still allows, from a write through a function to password verifiers and RLS.

What raised 'must be owner of table' in PostgreSQL 17, measured: which statements need ownership, which a grant covers, and how tables end up with mixed owners.

BYPASSRLS, table owners, FORCE and superusers in PostgreSQL 17, measured: who sees every row, what role membership passes on, and what RLS never covers.

The same LIMIT query on an idle Postgres: 78 ms, then 0.07 ms, with every page already in shared_buffers. Ten runs with a standard deviation and a per-run sample on each plan node found the cause (synchronize_seqscans), a control proved it, and the same statement returned different rows with nothing writing. Why one EXPLAIN ANALYZE is a sample of one, and how to read dispersion on a plan.

What raised 'permission denied for table', schema and sequence in PostgreSQL 17, measured: the privilege each statement needs, and why default privileges miss.

What current_setting and set_config do with a custom setting in PostgreSQL 17, measured: NULL or empty string, how long a value lasts, defaults, who may set it.