• in Postgres
  • 1 min read

Postgres Extensions Day 2025 Montreal: Registration and Call for Speakers

On May 12th, 2025, Postgres Extension Developers Coalition (PGEDC) will host Postgres Extensions Day 2025 in Montreal, QC.

It is a one-day, in-person event dedicated to the comprehensive exploration of Postgres extension – encompassing development, ecosystem, and operational concerns.

The program includes in-depth technical presentations, practical demonstrations, and structured discussions designed to foster collaboration and innovation. Whether you are new to Postgres extensions or an experienced developer, you will gain valuable insights, advanced techniques, and inspiration for your future work.

This free, community-led event operates independently and is unaffiliated with other events. Prior registration is required.

Call for Speakers is open until April 1st.

Topics of interest include:

  • Teaching extension development
  • Extension packaging & delivery
  • Libraries and frameworks for extensions
  • Gaps and challenges
  • Implementing extensions in different languages
  • Interesting techniques & discoveries
  • Operating extensions in production
  • Extensions security

If the topic above is not listed, please still feel free to submit your talk.

Register and submit your talks soon!

Omnigres Developer Experience

Software developer's job is not an easy one; anything that makes it less frustrating and makes developers more productive is highly sought for. This is why the most successful developer tools are usually the ones that have an amazing developer experience.

Omnigres turns Postgres into a complete Application Platform, and by doing that, we must focus on Development, Debugging and Deployment Experience (D3X) as the #1 priority.

Structured Postgres Regression Tests

I've been using pg_regress tests for a while. It's generally a great way to ensure the behavior of your Postgres code works and continues working as expected. However, as my tests became larger, I started getting lost in them; and there are limits as to what you can test by having a psql session.

Avoiding Postgres Extensions Limitations

Postgres extensions are great. They enable fantastic use cases and bring new capabilities to one of the most loved open source databases. But there are edges in some of its features and this can be heard in conversations: limitations of the upgrade system, lack of parameterized initialization, search path/OID resolution issues, hard-wired dependency on .control files, schema droppage 1, etc.

However, the beauty of it is that what we ultimately want from extensions does not need to use CREATE EXTENSION's framework.

Sum Types in Postgres

At times, representing the variety of types a value can take through multiple tables can taxing, both in terms of development complexity as well as, potentially, performance. You must just need a value to be of any of the given variants. I've set out to build a generalized mechanism for defining these.

What happens if you put HTTP server inside Postgres?

Benchmarks and performance claims are attention-grabbers, but that's not what drew me to work on Omnigres. When I first built a prototype of its HTTP server, I didn't foresee the desire to share the numbers. As we all know, getting benchmarks right is hard, and everybody's mileage may vary. But I'll show you some numbers here anyway. It'll be great to validate or invalidate my findings!

Why not Rust for Omnigres?

Omnigres is a new project to turn Postgres into a complete development and production deployment platform. I've started it to reflect on the complexity and inefficiencies plaguing modern business software development.

As an aging (and sometimes cranky!) developer, I crave simplicity. But that's a topic for another post. Here I wanted to address a common question:

Why didn't you implement this in Rust?