stevencodes.swe - June 8, 2025

Hey again 👋

This week I’m back with another snippet from Chapter 2 of The Backend Lowdown, a video I had a ton of fun making on Bloom filters, and a tool someone recently recommended that I’ve started exploring. Plus, a great comment thread from the community that got me thinking about how these ideas apply in practice.

Let’s get into it 👇

From The BackEnd Lowdown: How the Database Decides What To Do

Before your query runs, Postgres doesn't just dive in blindly - it pauses and asks: What's the most efficient way to do this?

That decision is made by the query planner , which looks at:

• The structure of your query

• The available indexes

• Freshness of table statistics

• Estimated row counts and costs

If an index exists on the filtered column, and the planner believes using it is cheaper than scanning, it'll take the index path. If not - say, because of outdated stats or low selectivity - it may choose a sequential scan , examining rows one by one.

This plan becomes the blueprint for how the database will fetch and process your data.

The planner evaluates multiple execution strategies - like using an index, scanning the whole table, or joining two tables in different ways - and chooses the one it thinks will be cheapest based on what it knows about the data. That decision depends on:

• Whether an index exists on the columns in your WHERE, JOIN, or ORDER BY

• How selective your query is (does it filter 5 rows or 5 million?)

• How many rows it expects to scan, join, or sort

Sometimes it picks correctly. Sometimes it guesses wrong - especially if table statistics are stale or the query is more complex than it looks.

To understand what the planner actually chose (and why), you use EXPLAIN. EXPLAIN generates a breakdown of how the database plans to execute your query - including which indexes (if any) it will use, what join strategies it will apply, how many rows it expects to process at each step, and how costly each operation is expected to be. And once you know how to read it, you can start spotting when it's choosing poorly - and how to guide it toward better plans.

Weekly Video Highlight

My favorite video this week is all about Bloom filters - a clever probabilistic data structure that lets you search massive datasets in constant time using very little space.

The catch? They can return false positives.

Despite that, they’re incredibly useful: CDNs use them to avoid duplicate requests, caches use them to skip missing key lookups, and databases use them to avoid cold disk reads. Check it out!

@stevencodes.swe

Need fast existence checks without loading huge datasets into memory? Bloom filters are the secret weapon behind modern caches, CDNs, and ... See more

Community Corner

This question came up on my Bloom filter video, and I loved it. It reminded me that even “simple” data structures have real world edge cases worth unpacking.

Dev Tool Highlight: Locust.io

Someone recently DM’d me about Locust.io , and it looks like an awesome tool I wish I’d known about sooner.

It’s a Python-based load testing framework where you can define user behavior in code - perfect for simulating real-world traffic. You can ramp up thousands of concurrent users, monitor system behavior, and catch bottlenecks early.

Given the topics I’ve been covering lately such as rate limiting, backpressure, and bounded queues, this feels like a super relevant tool to start experimenting with. I’ll report back once I’ve played with it!

That’s a wrap for this week. If something here made your day smoother, feel free to reply and tell me about it. And if you think a friend or teammate would enjoy this too, I’d be grateful if you shared it with them.

Until next time,
— Steven