Postgres Extensions Day 2025 Kicks Off with a Successful Debut in Montréal

Introduction

PostgreSQL Extension Day 2025 made its successful debut on May 12, 2025, just one day before the start of pgconf.dev 2025. This focused one-day event brought together the community around a single theme: the PostgreSQL extension ecosystem. From innovative ideas and development insights to discussions on safer extension building and delivery, the day was all about “everything extensions.”

The conference featured 14 tightly packed 25-minute talks, making for a long but highly productive day. For those unable to attend in person, the event was also live-streamed on YouTube.

Thanks to the hard work of the organizers and volunteers, PostgreSQL Extension Day 2025 turned out to be a great success. In this blog, I’ll walk through some of the key highlights and takeaways from this event.

Conference Highlights

Community and Volunteer Driven

Since this was the first-ever pgext.day conference, organized by Yurii Rashkovski, there was plenty of room for things to go sideways. Fortunately, a small but dedicated team—including Grant Zhou, Sweta Vooda, Charis Charalampidi, and myself—volunteered to support Yurii with setting up the live streaming and recording equipment early in the morning. Together, we handled the camera setup, microphones, projector, and streaming rig, and quickly got up to speed on how to operate the entire system before the event began.

I have to say, by the time the conference started, I felt surprisingly confident running the live streaming, camera work, and digital recording gear—a fun learning experience in itself!

Social

The social aspect of a conference is just as important as the sessions themselves—it’s where connections are made, ideas are exchanged, and the community truly comes alive. At pgext.day 2025, we had the chance to enjoy dinner together both before and after the conference, giving everyone time to relax, share stories, and get to know one another in a more informal setting.

Sponsors

pgext.day 2025 was made possible thanks to the generous support and efforts of:

Morning Talks

From pl/v8 to pl/ < any > : towards easier extension development – Hannu Krosing

• Enabling PostgreSQL function and extension development in any language via JavaScript-based language handlers.
• JavaScript as a gateway: Using JavaScript handlers allows transpiled languages (e.g., TypeScript, Python via Transcript) to become embedded PostgreSQL languages.
• pl/jsonschema: Uses AJV to validate JSON Schemas faster than pg_jsonschema (Rust-based).
• pl/wasm: Runs WebAssembly functions in PostgreSQL with near-native performance.
• add more feature support and extensibility with JavaScript including hooks and ability to modify plan trees or define a new types of executor nodes.
• basically wants to make postgresql more extensible to be even closer to the postgresql kernel.
• future web assembly support with javascript.

Upgrade as an extension – Andrew Borodin

• shared that upgrade could be a painful process especially with extensions. His team has achieved 2TB upgrade in a few minutes
• data corruption during upgrade due to a white space bug
• want stability, reliability, performance and fast development
• heap_moved_in and heap_moved_out not upgraded – keep in mind
• Tuples with invalid gist also not upgraded
• XLOG_PAGE_MAGIC changed 5 times per major release, and cause upgrade to restart postgresql as it is a physical change.
• catalog changes can be upgrade with extension but not fully.
• pd_pagesize_version has different values per major versions. sqlserver can automatically adjust pagesize based on version. → convenient

Inlining Postgres functions, now and then – Paul Jungwirth

• PostgreSQL can inline user-defined and built-in functions during query planning for performance benefits.
• Inlining allows SQL developers and extension authors to optimize query behavior.
• Aims to allow inlining of most Set-Returning Functions (SRFs).
• traditional SRFs have to be called multiple times to get all the rows it needs to return → lots of function call overhead costs.
• Enables a function to replace itself with a plan tree, integrating directly into the query planner.
• This approach effectively allows developers to write macro-like, query-integrated functions.
• inline function can only be written in C.
• avoid function call overhead in query intensive scenarios
• inline function can also return a query to pl/pgsql code to run without the function call overhead

Postgres a la carte: dynamic container images with your choice of extensions – Alvaro Hernandez

• Packing PostgreSQL extensions into container images is inefficient due to security and size concerns.
• Users may want arbitrary combinations of extensions, making static image generation impractical as there are just too many combinations.
• Dynamic OCI (container) images allow real-time, on-the-fly generation of PostgreSQL containers with only the selected extensions that automatically get installed to a postgresql instance running inside a container.
• work seamlessly in kubernetes and environment where OCI images are supported.
• performed a demo where the speaker has a pool of 80+ extensions and ask the audience to choose any extension that he will compile the image and inject to a running postgresql instance. (appeared in output of pg_available_extensions)
• This is made possible with DOCIR which is a dynamic OCI registry → open sourced
• some extensions require restart → still an issue
• experimented mounting container as a volume → still experimental
• extensions that depend on other extensions → still on going, not available today
• extensions that depend on third party libraries → no problem, can be packed in the same container image when built

Extension Upgrades – Yurii Rashkovski

• explained what extension is – it has control file, upgrade script, pgxs makefile
• explained the difference between upgrade and install path
• recommended to version everything including the .so file, docs, headers…etc
• one version of extension can be installed at one postgresql but difference postgresql may have different versions → conflicting objects.
• an extension currently feels like a side kick → postgresql native functions know nothing about extensions, nor do any other objects.
• postgresql only recognizes extensions files.
• for the sack of pg_upgrade, do not change any names in your extensions after the install. This includes .so name, upgrade script and control file names
• talked about install path (control file → execute .sql script → record dependencies)
• and upgrade path (control file → execute .sql script → execute next version .sql script → record dependencies)

Working with memory contexts and debugging memory leaks in postgres – Phil Eaton

• explained the memory context concept of postgresql and how it differs with traditional malloc and free
• memory is allocated to memory context in postgresql and automatically freed when the context’s life time ends. Also use pfree() to explicitly free a memory from a memory context.
• memory context is basically a tree structure and it can contain child memory contrext
• talked about memory leak and it can happen when we palloc too much → get killed by OS when all memory exhausted.
• several tools to use to find leaks:
  • memoryContextStats() outputs and gdb → hard to spot leakage but in some cases, it works well
  • bcc memleak → requires linux 4.1+ and works on aarch64 and macOS
  • heaptrack → inspired by valgrind, works on VMs, on aarch64/macOS, more efficient than valgrind
  • alternative malloc (jemalloc) – custom malloc implementation to track allocations and free
  • valgrind memcheck/massif → slow

postgres as a control plane: challenges in offloading compute via extensions – Sweta Vooda

• introduced pg_vector remote project that treats postgresql as a control plane to orchestrate external engines such as pinecone to offload pg_vector data
• explained the different scenarios where postgresql is used as a data and control plane
  • data plane: storage + compute in one place, indexes built-in, extensions live inside postgresql
  • control plane: orchestrate external engines via hooks, intercept DDL/DML and other operations and offload work outside of postgresql
• built a new index access method to work with pg_vector’s index. The new methods offload pg_vector index data to pinecone for storage and processing
• visibility checks and transaction states need to be maintained and synchronized to pinecone as well for consistency
• have some sort of state replication that will delete external data in case of a roll-backed transaction
• the use of batchng techniques to ensure higher throughput
• use of connection pool, keep alive to ensure stable connections to external servers
• pg-vector sends only ctid and any indexed metadata to external source to reduce payload

Afternoon Talks

the missing postgres extension repo and package manager – Ruohang Feng

• introduce the PIG tool from pigsty to easily, pull and build postgresql extensions as packages.
• explained the challenges with building extensions as packages in different versions and why it is hard even for developers:
  • combination exploding
  • rust extensions are slow and emerging fast
  • retired extensions do exist
  • name and libraries name conflict
  • extensions that do not work on vanilla postgresql
  • some extensions not well maintained
  • some extensions are too big
• his next plan is to build a reusable infrastructure for distribution maker and statistics about downloading, trending and hot extensions

how to automatically release your extensions on pgxn – David Wheeler

• No central distribution hub for PostgreSQL extensions; PGXN is the largest but only hosts about one-third of known extensions, many outdated.
• Become the root registry for all PostgreSQL extension releases to support automated downstream builds.
• A fully updated PGXN supports both extension developers and the wider PostgreSQL ecosystem.
• Session content:
  • How to set up PGXN distribution for your extension.
  • Tools to automate releases and keep extensions up-to-date.
• register an account in PGXN manager, download pgxn command line tool, draft a META.json to include required information about the extension.
• release with one command
• pgxn tools can do OCI image, package and upload releases, use in CI/CD
• GUI to check releases

extending postgresql with java – overcoming development challenges in bridging java and c applications – Cary Huang

• introduced the synchdb project that serves as a case study where java and C are both use to create a postgresql extension
• presented the architecture of dual language extension with JNI as bridge
• presented the compatibility problems with dual language extension such as:
  • signal handler conflict
  • memory architecture
  • concurrency issues
  • synchronization
  • exception handling checks
  • throttle control
• discussed that foreign function and memory interface (FMI) may be the better successor to JNI
• discussed that graalvm may be another alternative to turning java stuff to native C shared libary which is the most native and does not require jvm

Rethinking OLAP Architecture: The Journey to pg_mooncake v0.2 – Cheng Cheng

Unfortunately, I was caught up in a great hallway conversation right after my talk and wasn’t able to attend or take notes for this session. Luckily, my colleague Grant Zhou managed to capture a few photos during the talk—so while I can’t offer a summary, I’m happy to share these snapshots from the session:

Hijacking shared memory for a redis-like experience in postgresql – Florents Tselai

• shared memory is traditionally used internally by databases for query execution, caching, and transaction management.
• proposed using shared memory for user-facing, high performance data cache like Redis
• introduced Spat, which is a Redis like in-memory data structure server embedded in postgresql
• spat operates outside postgresql transaction control, no MVCC, no WALL no rollbacks:
  • support non-rollbackable changes
  • no transaction isolation
  • in memory only
  • write locks in concurrency
• all spat data stored in shared memory, can be hashes or key-value pairs
• offered a lightweight, fast option for ephemeral storage within postgres
• still alpha, not production ready
• future improvements include:
  • C API for other extensions
  • redis/valkey wire protocol
  • more data strucutures
  • improve monitoring of shared memory usage

cppgres: one less reason to hate c++ – Yurii Rashkovski

• Writing PostgreSQL extensions in C is often cumbersome, error-prone, and repetitive.
• Many developers avoid it due to complexity, but modern C++ (C++20) offers powerful, safer alternatives.
• Modern C++ can deliver similar ergonomics and safety without switching toolchains.
• introduced cppgres
  • A lightweight, header-only C++20 library for PostgreSQL extension development.
  • Designed to streamline, safety-proof, and simplify extension code.
  • automatic type deduction
  • clean, readable, performant extension code
• goal is to change perceptions about c++

Extensibility – new options and wish list– Alastair Turner

• users want to know what is going on in PostgreSQL per query and over time.
• PostgreSQL is becoming more extensible in various functionalities such as:
  • EXPLAIN → custom scans and contents can be injected into EXPLAIN output
  • statistics
  • COPY formats → can support formats such as JSON, parquet, iceberg
  • logging → extensions can create custom log entries
• pg_overexplain extension exposes many internal planner data structures
• extensible COPY format → optimization is done on built-in COPY formats
• extensions can overwrite the entire storage layer similar to:
  • Neon
  • Oriole
• extensions can also support pluggable transparent data encryption (TDE)
• future of storage manage extensibility
  • Percona is working on a patch to enable TDE via extension