Markus Winand's use-the-index-luke.com is one of the most quietly influential resources on the internet for anyone who touches a relational database. It's the companion site to SQL Performance Explained, and this particular post tackles a design choice that most developers never question: why is the primary key almost always the clustering key by default?

On engines like SQL Server and MySQL/InnoDB, tables are physically stored in primary-key order (a "clustered index"). Every non-clustered index then stores the primary key as its row pointer rather than a direct heap address. Winand's argument, based on the URL and title, is that this default is unreasonable: every secondary index inherits the width of the primary key, and every lookup through a secondary index pays an extra B-tree traversal to reach the actual row. On a table with a wide composite PK or a UUID, this "clustered index penalty" compounds across every additional index you add.

Why this matters for a technical audience:

• UUID primary keys are everywhere now. Distributed systems, event sourcing, and microservices lean heavily on UUIDs. If you're on InnoDB or SQL Server, each of your secondary indexes just got 16 bytes wider per row — with corresponding cache-miss and IO implications.
• The advice is engine-specific and counterintuitive. PostgreSQL doesn't cluster by default (it uses heap tables), so Postgres developers reading this get a useful reminder of why cross-engine performance advice doesn't transfer cleanly.
• It challenges an "obvious" default. Winand suggests the clustering key should be chosen based on the workload's dominant access pattern, not blindly inherited from the PK. That's a small idea with large downstream consequences for schema design reviews.

Although the post is from 2014, the underlying trade-offs haven't changed — if anything, they've become more relevant as UUIDv7 and ULIDs push developers toward wider primary keys. It's the kind of foundational database content that ages extremely well, and the reason use-the-index-luke keeps getting re-shared: it explains why your query is slow, not just how to add another index.