PostgreSQL Conference Germany 2026

Our PostgreSQL products are 100% open source, with zero product level differentiation between users and customers. Everyone gets the same software. Period. That usually earns us a few wide eyed looks, followed by the inevitable question: "So… how do you make money?" The answer is simple: we focus on making the software exceptional. Truly great products help users succeed, build real businesses and grow with confidence. When they need help scaling further, they choose Percona for best in class support, consulting and managed database services. This model isn't theoretical, it's proven. We've been doing it for more than two decades, customers have quite literally voted with their wallets, choosing Percona for both our open source products and our expertise. That trust has allowed us to grow steadily and sustainably, without compromising our open source values. This is what we call sustainable open source!

We believe an open world is a better world. Our mission is to enable everyone to innovate freely, by providing the best open source database software, support, and services. Percona exists to push boundaries through open source — to accelerate innovation for everyone, everywhere.

That's a tricky question, because we can't really pick just one.

• Patroni and pgBackRest (tie) High availability and enterprise grade backups are non negotiable for serious PostgreSQL deployments. Patroni and pgBackRest together bring PostgreSQL to the level of reliability and resilience our customers and users alike expect from enterprise solutions. These two provide that, without abandoning open source values.

• pg_tde Transparent Data Encryption has long been a painful gap in PostgreSQL. Proprietary vendors have used this to pull users into closed solutions built on top of PostgreSQL. With pg_tde, there is now a fully open source alternative. Users can meet security and compliance requirements without sacrificing openness, transparency, or control.

• pg_gather This one is close to our hearts. pg_gather is heavily used by our Support team. It actually comes from Percona Support, but that's just to the point. The team delivered a tool that enables efficient troubleshooting of complex, real world issues and helps deliver the high quality services our customers rely on. It directly improves how we support users, which makes it critically important to our business.

So we’ve asked our support experts and there was no hesitation about it as we’ve received an answer along the lines of: “Of course lack of Global Temp tables.” So to give some background, we often see users suffering due to that lack of standard compliance. For larger organizations, temp tables are especially a cause of pain. As this issue is painful to larger users, there is a lot of value in Community putting more attention to solutions like https://commitfest.postgresql.org/patch/2349/

Playing by the rules is overrated, we'll give you at least two missing features, not one.

1. Unlogged Materialized Views. PostgreSQL is currently enforcing WAL logging on all materialized views that are essentially providing us with a "cache" of queries that can be rebuilt at any time. Clearly in such scenarios the WAL logging overhead is unnecessary for most use cases.

2. `wal_level` to logical set table at table-level. Currently when we need to enable `wal_level` to `logical` for the entire instance, just to replicate one or two tables to downstream / warehouse / lakehouse we cause a huge wastage that is also causing quite a lot of problems We could introduce quite significant operational savings and performance gains if we simplified the process to replicate a couple tables in such scenarios.