Index bloat in Postgres can cause problems, but it’s easy to miss.

I’ve written about how vacuum problems can prevent PostgreSQL from using covering indexes, and index bloat is one of the things that can make vacuum struggle.

Here’s what you need to know about index bloat, how to find it, and how to fix it.

I frequently need to see rowcounts and execution time for queries while they’re running. Maybe I’m troubleshooting a slow query that’s still executing, or I want to understand which operators are causing the slowdown before the query completes.

Last week at the PASS Summit I learned some little nuances about how this works that I’d missed.

While every managed database service has high points and low points, there are three things that make RDS for SQL Server shine in comparison to Azure SQL Managed Instance: options for a higher memory:vCPU ratio, a well documented API that works beautifully with python, and fast and effective customer support that isn’t painful to use.

It’s just three things, but they make a huge difference. And these are three things that Microsoft can, and SHOULD, really fix for their cloud database services.

Dear Postgres, Why won’t you use my covering index?

Lately I’ve been learning to tune queries running against PostgreSQL, and it’s pretty delightful. One fun question that I worked through struck me something that most Postgres users probably encounter one way or another: sometimes you may create the perfect index that covers a given query, but the query planner will choose to ignore it and scan the base table.

Why in the world would it do that?

Joins are essential. The SQL Corgs introduce you to INNER joins in this animated short. When you need to combine data from multiple tables, INNER joins are your go-to tool: they only return rows where there’s a match in both tables.

Watch as Freyja and Stormy demonstrate how matching on color brings their favorite toys together, with sample code you can run yourself.

Why do we “normalize” relational databases, and what are the basics? Awkward Unicorn explains, with a little help from their friends.

Database normalization helps you organize data efficiently, reduce redundancy, and prevent update anomalies. It’s one of those foundational concepts that makes everything else in database design make more sense.

Freyja the corgi shares her tips for learning SQL: SELECT, FROM, and WHERE. These three keywords form the foundation of almost every query you’ll write. SELECT tells you what columns to return, FROM specifies which table to query, and WHERE filters the rows.

Once you’ve got these down, you’re well on your way to writing effective SQL queries. Now that I’m getting the hang of this, I think I’m going to do a whole series of shorts on SQL syntax essentials, plus tips and tricks!

I learned to make short form videos with my drawings this week, and, well… things are about to get weirder. Meet Rita the Raccoon, who’s here to help explain SQL concepts in a way that’s both educational and delightfully unexpected.

This is the first in what I hope will be a fun series of animated SQL tutorials featuring my favorite characters.