Firefly2026-09-082026-09-081https://pgday.uk/events/pgdayuk2026/schedule/08:0000:45Otherhttps://pgday.uk/events/pgdayuk2026/schedule/session/332/PGDay UK08:4500:10Auditoriumhttps://pgday.uk/events/pgdayuk2026/schedule/session/334/PGDay UKDave Page09:0000:50AuditoriumPostgreSQL 19 is almost done, with expected release date right around the corner. This presentation will give a rapid walk-through of what is part of the new version. It may not be time to upgrade just yet, but it is definitely time to start planning!https://pgday.uk/events/pgdayuk2026/schedule/session/293/General TalksMagnus Hagander10:0000:50AuditoriumHow do you backup (and restore) a +100TB database? Well, maybe you don't. In this talk I will share the singularities I encountered when managing huge PostgreSQL databases, like backups, high availability challenges, how to keep vacuum under control... When reading blog articles, the best practices, the "how to" guides, things seem straightforward, but when you start bending PostgreSQL limits, you will end up needing to question the most fundamental assumptions on about how PostgreSQL works. Over the last years, my team has been exploring the boundaries of what PostgreSQL can do and today I will share our findings with you (at least the ones I can!).https://pgday.uk/events/pgdayuk2026/schedule/session/276/General TalksTeresa Lopes10:5000:20Otherhttps://pgday.uk/events/pgdayuk2026/schedule/session/335/Breaks11:1000:50AuditoriumPostgreSQL has many different parameters divided into in various sub-categories. This talk will cover some of those important parameters in each section, highlighting how to monitor them and when to tune them. Sections and parameters covered in this talk would include : Connection and authentication - max_connection, ssl ; Resource Utilization (Memory)- shared_buffers, work_mem, maintenance_work_mem, autovacuum_work_mem ; Write-Ahead-Log - wal_level, full_page_writes, checkpoint_timoeout, max_wal_size; Replication - wal_keep_size, max_slot_wal_keep_size, max_standby_streaming_delay, max_standby_archive_delay, hot_standby_feedback; Reporting and Logging - log_min_duration_statement, log_statement; Autovacuum - autovacuum_max_workers, autovacuum_freeze_max_age. We will cover in details the importance of some parameters and how they are connected, interacting with the database resources.https://pgday.uk/events/pgdayuk2026/schedule/session/277/General TalksDivya Sharma12:1000:50AuditoriumWhat does it take to build a Postgres proxy that applications can't tell apart from vanilla Postgres? In this talk, I share lessons from building Multigres, a horizontally-scalable Postgres proxy. We'll walk through the real compatibility challenges we faced: implementing COPY FROM STDIN as a streaming state machine, managing session state and transactions with connection pooling, preserving all 14 Postgres error diagnostic fields through a gRPC stack, handling TLS negotiation, forwarding NOTICE messages, and forwarding client startup parameters. Then we'll see how we used Postgres's own regression and isolation test suites to measure and prove what it truly means to be a transparent Postgres proxy.https://pgday.uk/events/pgdayuk2026/schedule/session/265/General TalksHaritabh Gupta13:0000:40Otherhttps://pgday.uk/events/pgdayuk2026/schedule/session/337/Breaks13:4000:50AuditoriumReproducible production environments are more important than other “nice to have” features: they enable successful deployments, performance testing, and fast incident response, by minimizing uncertainty and reducing downtime when most needed. We will explore how TPA can help with replicate your Postgres production cluster, by enabling reproducibility as a solid engineering practice leading to improved performance confidence, safer deployments and overall system resilience. We will conclude with a practical example where we reproduce a production environment and then carry out performance testing at 1:1 scale while keeping cloud costs negligible.https://pgday.uk/events/pgdayuk2026/schedule/session/317/General TalksGianni Ciolli14:4000:50AuditoriumCloudNativePG has made running PostgreSQL on Kubernetes reliable and production-ready. It provides high availability, streaming replication, and automated failover. This however, adds a lot of moving pieces, which makes performance tuning an even larger challenge. Most PostgreSQL tuning advice assumes a static server: a fixed amount of RAM, predictable CPU access, direct edits to postgresql.conf, and a primary that never moves. None of those assumptions hold in a CloudNativePG cluster, where PostgreSQL runs inside Pods with strict resource limits, configuration is declarative, and the primary can change at any moment. What exactly do you need to be aware of when tuning in this dynamic environment? What are the new risks—and the automated possibilities? In this talk, I share a case study on tuning a highly available CNPG cluster without guesswork or downtime. We will move beyond "safe" defaults to address the specific technical kinks of the CNPG stack: The Container Illusion: How Cgroup limits change the fundamental math for memory and parallelism. Operator-Led Optimization: Applying configuration safely via the CNPG operator without restarts or configuration drift across replicas. HA-Aware Tuning: Handling primary failovers mid-session without corrupting measurement results or losing cluster stability. Dynamic Planning: Why statistics and planner behavior matter more in shifting, containerized environments. Using a 3-instance cluster and a realistic stress workload, we validated this methodology with automation (eliminating human error and accelerating iteration). The result: 4.5× improvement with zero downtime. Whether you apply this manually or with tooling, the principles remain the same. Attendees will leave with a repeatable, data-driven blueprint for tuning PostgreSQL responsibly on Kubernetes.https://pgday.uk/events/pgdayuk2026/schedule/session/257/General TalksMohsin Ejaz15:3000:20Otherhttps://pgday.uk/events/pgdayuk2026/schedule/session/336/Breaks15:5000:50AuditoriumGetting your amateur radio license opens up all sorts of fun. One interesting example is Active Packet Reporting System (APRS), basically sending your location information out over the airwaves. The data is gathered up and available on a web site, APRS.fi. However, you only get limited reporting from the data there. In order to have more fun with that data, I've built a Lambda Function on AWS to pull data into an Aurora PostgreSQL database that has the postGIS extension. With all that in place, I can then use my APRS data in much more interesting ways to display all sorts of exciting reports thanks to the functionality offered through postGIS. This session will be focused on showing you how all the processes are brought together in order to demonstrate just how much you can do with PostgreSQL and postGIS. Putting PostgreSQL to work doesn't have to be hard, especially on fun projects.https://pgday.uk/events/pgdayuk2026/schedule/session/271/General TalksGrant Fritchey16:4500:15OtherThank you everyone attending and we'll say good bye for this year.https://pgday.uk/events/pgdayuk2026/schedule/session/340/PGDay UKDave Page