Please note different time and location this month at UpStart Collective at the U.S. Bancorp Tower (a.k.a. Big Pink). Please RSVP on MeetUp. Tuesday September 8, 2026 from 6:30pm to 8:30pm.
Coinciding with devopsdays Portland, OR, Sept 8-10, 2026.
In v18, Postgres got temporal primary keys, unique constraints, and foreign keys (with `NO ACTION`). Hopefully in v19 we’ll have `UPDATE/DELETE FOR PORTION OF`. So it’s a good time to start thinking about migrating your schema to a temporal structure. Some advantages include:
– Easier queries and joins to reconstruct historical data.
– A better way to do soft-deletes (preserving referential integrity).
– No bugs from foreign key references to since-updated data.
– A less ad hoc way of representing historical data.
This talk will explore how to migrate your schema to include application-time `daterange` and `tstzrange` columns. I’ll use an existing schema for a time-tracking and invoicing application (used by me for over 12 years), showing the pain points of the old structure, not sparing my pride at some bad decisions, and give an approach to bring it all into a nicer temporal structure.
We will also talk about some remaining pain points in using temporal tables, and suggestions to mitigate them.
If you are contemplating a move to temporal tables, this talk will give you an overview of the landscape.
Presented by Paul Jungwirth:
Paul is a freelance software developer in Portland, Oregon.
He has built applications with Postgres since 2010 and is the author of several extensions.
His Postgres contributions include work on GiST indexes, multiranges, and SQL:2011 application-time features.