PostgreSQL events are often where the past, present, and future of the database intersect, and FOSSASIA PGDay Bangkok 2026 was one of those moments.
The PostgreSQL Community comes together at FOSSASIA PGDay Bangkok
FOSSASIA Summit 2026 was held in Bangkok earlier this year, bringing together over 200 international speakers across tracks spanning AI and Data, Cloud and DevOps, Cybersecurity and Privacy, Web and Mobile Development, and Open Hardware. Among the featured tracks was PGDay, a dedicated PostgreSQL conference running as a full day within the broader summit, and one of the more significant PostgreSQL gatherings in the Asia-Pacific region.
FOSSASIA PGDay has, over the years, been hosted across Singapore, Indonesia, Vietnam, and Thailand, consistently bringing together the regional PostgreSQL community to exchange knowledge and collaborate. The 2026 Bangkok summit was no exception.
The PGDay programme covered core development, performance and indexing, high availability and disaster recovery, backups, security, and operational practices. The day also included time for discussion and informal networking with speakers and community members.
From PostgreSQL internals to enterprise experience
Beyond the keynotes, the schedule featured sessions on extensions and PostgreSQL internals work, including pg_ivm, pg_fusion, and Biscuit, as well as a hands-on session with PostgreSQL 18 demos. It was a well-rounded programme that reflected both the depth of PostgreSQL as a technology and the maturity of its community, ranging from committer-level internals to production stories from the field.
Fujitsu was among the organizations represented at the Summit with four presentations delivered in the PGDay programme. I presented alongside my colleague Rajni Baliyan, who contributed two talks of her own, one looking at how PostgreSQL support is evolving in the age of AI, and another exploring how the database continues to thrive through open collaboration within the community. Rajni will be sharing more details in an upcoming blog post, so be sure to subscribe to be notified when it goes live.
All talks explored themes that sit at the core of how Fujitsu thinks about PostgreSQL, its long-term viability as an enterprise platform, enterprise support, and the evolution of its replication capabilities into something approaching infrastructure-grade reliability.
If you weren’t able to attend the event in person, I am making my presentations available at the end of this post 
Talk 1: Thirty years of PostgreSQL (Survival and Adaptation) - Keynote
I opened PGDay with a keynote that took a step back from day-to-day engineering to ask a broader question of how does an open-source database project not just survive, but thrive, across three decades of relentless change?
PostgreSQL's journey is one of the more remarkable stories in software. Originating from academic research at UC Berkeley in the late 1980s, it became a community-driven open-source project at a time when few people would have bet on that model succeeding against commercial incumbents. What followed was a sustained gauntlet of technological disruption, each wave threatening to make relational databases, and PostgreSQL specifically, obsolete.
The talk walked through those challenges in roughly chronological order. First came the object-relational push of the 1990s, when it seemed the future of data management would be built around complex object hierarchies, PostgreSQL absorbed that thinking into its extensible type system rather than fighting it. Then came XML as the universal data format, and with it the assumption that relational models would give way to document-centric architectures, PostgreSQL adapted by building solid native XML support. The NoSQL wave of the mid-2000s was perhaps the largest threat, the argument that schema-on-write was simply wrong for modern applications gained significant traction, and yet PostgreSQL responded not by abandoning its relational foundations but by adding first-class JSON and JSONB support, effectively offering a document store inside a transactional database.
New pressures without new fundamentals
The cloud era introduced a different kind of pressure, not a new data model, but a new delivery mechanism. Cloud-managed PostgreSQL services democratised access to the database, which was genuinely good for the ecosystem, but also created tension around what 'Enterprise PostgreSQL' means when anyone can spin up a compatible instance in minutes. More recently, AI and vector workloads have landed, with pgvector positioning PostgreSQL as a capable platform for embedding storage and similarity search, again, an extension to the core rather than a fork away from it.
The theme of the talk was that PostgreSQL's longevity isn't accidental. It comes from a set of architectural decisions made early, particularly around extensibility, that gave the community the ability to respond to new demands without compromising the integrity of the core. The governance model matters too, a conservative committer culture that resists hype-driven feature bloat has kept PostgreSQL remarkably stable over time, even as the world around it has changed completely.
For Fujitsu, this history is directly relevant. Fujitsu Enterprise Postgres is built on the foundation of that thirty-year investment, extending it for the specific demands of enterprise environments, not replacing it, but deepening it. Understanding why PostgreSQL has lasted this long is essential to making credible claims about its future.
Talk 2: Logical Replication as Infrastructure (Conflicts become explicit in PostgreSQL 18)
The second presentation took a more technical turn, exploring how logical replication in PostgreSQL is undergoing a quiet but significant transformation, one that matters enormously for organisations using it for zero-downtime upgrades, multi-region deployments, and active-active architectures.
The talk opened by reframing what logical replication actually is. It's often described as a feature, something you turn on to move data between clusters. But the better mental model is infrastructure, a persistent, low-level mechanism that underpins some of the most critical operational patterns in modern PostgreSQL deployments, from major version upgrades without downtime to cross-region data distribution. When you treat it as infrastructure, your expectations of it change. Infrastructure doesn't fail silently. Infrastructure makes problems explicit so extensions and programs layered on top can respond. Infrastructure has observable state.
For much of PostgreSQL's history, logical replication has fallen short of that standard when things go wrong. When a conflict arose, two nodes editing the same row simultaneously, or a local write on a subscriber clashing with an incoming replicated change, the replication worker would simply stop. Extensions and software leverages logical replication were left checking logs, finding the LSN, and manually skipping the offending transaction. This is workable in simple topologies, but it doesn't scale operationally, and it's genuinely risky in complex deployments where replication lag has downstream consequences.
Making replication state and conflicts explicit in PostgreSQL 18
PostgreSQL 18 introduces a formal conflict detection framework. Rather than failing blindly, the system now identifies the collision at the point of application, comparing the remote tuple coming from the source against the local tuple already on disk before deciding what to do.
The changes in PostgreSQL 18 make conflicts explicit in several concrete ways. Detailed conflict logging now specifies exactly which row, which table, and what type of conflict occurred, making it possible to respond programmatically rather than by guessing from cryptic error messages. The new pg_stat_subscription_stats view surfaces granular conflict counters including confl_insert_exists, confl_update_origin_differs, confl_update_exists, confl_update_missing, confl_delete_origin_differs, and confl_delete_missing, giving operators a clear picture of subscription health over time.
This is significant in itself, but the talk positioned it as a stepping stone rather than a destination. The community roadmap points toward a conflict_resolver parameter in CREATE SUBSCRIPTION, offering configurable resolution strategies such as stopping and waiting for manual intervention, applying the remote change unconditionally, keeping the local version, or using timestamps to determine which version wins. That's the trajectory towards replication as programmable infrastructure.
PostgreSQL - Why it is still here after 30 years
Click to view the slides side by side
Top to bottomClick to view the slides in vertical orientation
Logical Replication is infrastructure
Click to view the slides side by sideTop to bottomClick to view the slides in vertical orientation
A community effort, well reflected in Bangkok
FOSSASIA PGDay Bangkok 2026 was a strong reminder of why PostgreSQL continues to succeed after more than thirty years: not because it stands still, but because it evolves through collaboration, careful engineering, and a community that values long‑term integrity over short‑term trends. From architectural discussions to practical operational insights, the programme reflected a project that is both mature and actively moving forward.
For Fujitsu, participating in PGDay is about contributing to that shared journey, engaging with the community, learning from real‑world experience, and helping shape PostgreSQL into an increasingly infrastructure‑grade platform for the future.
Events like this reinforce that PostgreSQL’s strength lies not just in its features, but in the people and collaboration behind them.
Photo gallery
