Fujitsu’s PostgreSQL journey
There are no shortcuts into the PostgreSQL community. It is one of the few large open-source projects with no single corporate owner, no fast track, and no way to buy influence. Standing is earned the slow way… patch by patch, on public mailing lists, under the scrutiny of reviewers who will tell you plainly when an idea isn't ready. A first submission is rarely the version that gets committed. What gets you from a rejected patch to a trusted contributor is the willingness to keep showing up, take the feedback, do the work, review others' patches in turn, and prove over many release cycles that your judgment can be relied on.
That is the path my team of Fujitsu engineers working full-time on PostgreSQL has traveled. We didn't arrive as authorities; we arrived as participants, learning the culture of the commit fests, the pattern of the development cycle, and the high bar the community sets for anything that touches a database people trust with their most critical data. Over many releases, our persistence has compounded from isolated fixes into sustained ownership of meaningful areas of the logical replication codebase, which is the key factor to achieve multi-master PostgreSQL system, and from unknown names on a thread into engineers whose reviews and designs carry weight.
A marker of that progression is recognition from the community itself. This year, Zhijie Hou was named a PostgreSQL major contributor, a distinction the project reserves for those whose work has materially shaped the database. It reflects years of effort across logical replication and beyond. Hou's recognition sits alongside the growing footprint of our wider team, whose names now appear regularly in commit logs, release notes, and reviewer credits.
This post looks at our footprint in the PostgreSQL 19 development cycle. We've gathered our contributions, the features and fixes we've authored, the commit statistics behind them, and the areas of the project where our work landed to show how our team shows up as an active, committed contributor to one of the world's most important open-source databases.
Statistics of contributions to recent versions
Fujitsu has been submitting and reviewing patches for years. For PostgreSQL 19, we authored 83 commits and reviewed 81 commits. The table and graph below show the transition for the 5 recent versions.
| Version | Commits authored by Fujitsu |
Commits reviewed by Fujitsu |
| PostgreSQL 15 | 49 | 41 |
| PostgreSQL 16 | 56 | 46 |
| PostgreSQL 17 | 72 | 76 |
| PostgreSQL 18 | 80 | 85 |
| PostgreSQL 19 | 83 | 81 |
The total number of contributions has increased by around 1.8 times over the past 5 years, reflecting steady growth across multiple release cycles. These numbers indicate that Fujitsu has been on a long journey to this point. In the early stages, we were still building trust and credibility within the community, which gave us room to grow into more effective, collaborative contributors. Over the years, we have persistently discussed with others, submitted and reviewed patches proposed by others, and fixed bugs. Now our work is well recognized by the community, and our contributions are relied upon at a consistently high level, so everyone on the team can exercise their abilities.
Note: the exact number mentioned in the section might differ from other articles due to the counting method.
Recognition from the community
The PostgreSQL community has recognized Fujitsu's contributions, and several of our team members have been recognized as listed contributors. I would like to share some recent recognition updates.
Zhijie Hou is now recognized as a major contributor to PostgreSQL. He has significantly improved performance and written several features of logical replication. For example, parallel apply could improve performance by 25-40% when applying streamed large transactions; he was the main author. He has also been developing infrastructure for the multi-master replication system, including conflict detection. He continues to make significant contributions through feature reviews and bug fixes for logical replication.
Shveta Malik has also been recognized as a significant contributor to PostgreSQL. She is a passionate PostgreSQL hacker who reviews most logical replication proposals and helps shape them into their final designs. She has been improving the availability of logical replication and making it user-friendly. One example is slot synchronization. It keeps logical replication slots on the streaming primary and standby in the same state, allowing users to continue logical replication after the failover. Her expertise has been instrumental in improving patch design and quality and in driving community discussions forward.
Our team now includes four recognized PostgreSQL significant contributors, including one major contributor. If you want to know the whole team structure and contributions by us, check our blog post How Fujitsu helps drive PostgreSQL forward with code-level contributions and features.
Notable features
In this section, I will introduce several features listed in the release note. Below are the features available in PostgreSQL 19 beta as of July 2026, but some may be reverted before release.
Allow table exclusions in publications
We allow excluding specific tables from FOR ALL TABLES publications. Previously, a FOR ALL TABLES publication included every table in the database, requiring users to create publications with explicit table lists if they wanted to omit a few tables. This feature makes FOR ALL TABLES publications more flexible by allowing users to exclude selected tables while continuing to publish all others.
Peter Smith introduces the feature in more detail in his PostgreSQL Zone article Excluding tables from publications in PostgreSQL 19.
Logical replication of sequences
We allow sequence synchronization in logical replication, which has long been recognized as one of its main challenges. The main use case for logical replication is instance upgrades, but users must manually synchronize sequence values across instances. In PostgreSQL 19, the synchronization can be done by running a new SQL command: ALTER SUBSCRIPTION … REFRESH SEQUENCES. This solves a long-standing weakness in PostgreSQL's logical replication story and makes the online upgrade easier.
The actual usage of this feature is discussed in Closing a critical gap in PostgreSQL upgrade workflows with sequence synchronization.
Detect update_deleted conflict
Conflict Detection in Logical Replication was introduced by our team. In PostgreSQL 19, we extend this capability by adding detection of the update_deleted conflict, a case that has traditionally been hard to distinguish from the existing update_missing conflict.
The update_deleted conflict is reported when a subscriber subscribes to multiple publishers, or when the subscriber itself updates tuples, and the tuple being updated has been concurrently deleted by another origin. This provides the infrastructure for conflict resolution in logical replication, which is an important building block toward multi-master replication.
Allow dynamically adjusting wal_level
We allow dynamically adjusting wal_level based on the existence of logical slots. Creating the first logical slot raises the effective WAL level to logical, even if wal_level is configured as replica. Dropping or invalidating the last logical slot causes it to be lowered asynchronously by the checkpointer process. This makes logical replication available seamlessly, improving efficiency and usability.
Shveta Malik discusses the feature in her post Online WAL level change for logical decoding in PostgreSQL 19.
Improve several points for slot synchronization
The slot synchronization feature was introduced in PostgreSQL 17 and can be used for fault-tolerant logical decoding and replication even after a failover. In PostgreSQL 19, we provide new statistics that show how many times synchronization was skipped and the reasons for each skip. Also, the SQL interface has been improved to retry synchronization on failure. This feature improves the availability of the logical replication system and makes it more usable for enterprise systems.
Wrap-up and what’s next
The contributions gathered here tell the consistent story that my team of engineers are not occasional participants in PostgreSQL but a sustained presence in its development. Across the PostgreSQL 19 cycle, our work landed in areas the whole community relies on, and the recognition has followed. It reflects standing earned through years of patches, reviews, and a steady accumulation of trust.
What matters most is that this isn't a finish line. PostgreSQL's strength has always come from contributors who keep showing up cycle after cycle, and my team at Fujitsu intends to do exactly that, carry this momentum into PostgreSQL 20 and beyond, continuing to review others work as readily as we submit our own, and invest in the health of the project rather than just its features. The work in PostgreSQL 19 is one chapter; the commitment behind it is ongoing.
PostgreSQL Insider 
