After more than 25 years helping customers and partners build and troubleshoot SQL Server applications, both on-premises and in the cloud, I began working with PostgreSQL and quickly discovered that some of the things I assumed were “obvious” were not universal after all.
Not the fundamentals: an 8 TB database with roughly 80% unused indexes, or a supposedly “slow” web page firing off 63 separate database queries—those problems still exist 😊. But the defaults, the tools, and especially the failure modes are different enough to create trouble if you are not paying attention.
This talk comes out of those moments. We’ll walk through a few patterns I’ve encountered—and sometimes introduced myself—including chatty applications, accidental N+1 queries, parameterization surprises, pagination that breaks down at scale, and schema changes that seemed safe until they were not.
For each one, we’ll look at how it appears in PostgreSQL, why it behaves that way, and how to fix it, often contrasting it with the approaches I used on SQL Server.
We’ll also look at cases where the platforms are just different. For example, without built-in resource governance, one bad query can suddenly slow everything else down—and now the fix is no longer in the database, but in how your application behaves.
This is not about comparing databases. It is about building a mental model you can carry with you. You’ll leave with practical ways to read execution plans, think about indexes, and troubleshoot performance issues without instinctively blaming the database.