PostgreSQL Indexes Without the Overhead
A practical look at what indexes solve, what they cost, and how to reason about them before adding one.
// TABLE OF CONTENTS+
05DiscussionAn index is a tradeoff
Indexes can make reads dramatically faster, but they are not free. They consume storage and add work to writes.
| Without index | With index |
|---|---|
| Sequential scan | Index lookup |
| More rows examined | Fewer rows examined |
| Simple writes | Additional index maintenance |
index.sqlsql
CREATE INDEX articles_published_at_idx
ON article (published_at);| Query | Likely concern |
|---|---|
| WHERE slug = ? | Uniqueness |
| ORDER BY published_at | Ordering |
| WHERE category_id = ? | Filtering |
// RECENT ARTICLES
01
What Actually Happens When You Visit a Website12 Sept 2026
→02Server Components Changed How I Think About React10 Sept 2026
→03Designing a Clean Data Boundary in Next.js08 Sept 2026
→04Why I Stopped Putting Database Queries in Components06 Sept 2026
→05Designing a Structured Portfolio Content Model05 Sept 2026
→06What I Actually Learned Building This Portfolio05 Sept 2026
→
OPEN
Thoughts on the article.
This is a useful explanation of the write cost of indexes. It is easy to think of an index as a completely free read optimization.
The query-pattern-first approach makes indexing much easier to reason about. I especially liked the emphasis on measuring before adding indexes.