Real Problem They Solve: Why PostgreSQL INCLUDE Indexes Deserve a Second Look
PostgreSQL INCLUDE indexes get a lazy explanation most of the time. Developers hear that they enable index-only scans, and they move on. But that explanation skips the more interesting story underneath. This story follows Real Problem They Solve.
As franckpachot explains in a recent Dev.to post, PostgreSQL could already build covering indexes before version 11. You just added extra columns to the index key itself. So why did the project add a whole new INCLUDE clause in PostgreSQL 11?
The Hidden Cost of Extra Key Columns
Putting a column in the index key isn’t free. Every key column gets sorted, compared, and stored in the index’s B-tree structure.
That sorting matters for uniqueness checks and range scans. But if you only need a column for output, not for searching or ordering, sorting it is wasted work.
PostgreSQL INCLUDE indexes fix this specific waste. They let you attach payload columns to an index without forcing those columns into the sorted key.
The result is a leaner B-tree. Unique constraints still work correctly, because only true key columns count toward uniqueness.
Index-Only Scans Are the Visible Benefit
Index-only scans still matter here. When every column a query needs lives in the index, PostgreSQL can skip the heap entirely.
That skips a slow trip to the actual table rows. For wide queries on narrow tables, this shaves real time off every execution.
But as the article points out, that benefit already existed before INCLUDE. The real upgrade is efficiency inside the index structure itself, not the scan strategy.
A Broader Pattern: Small Design Choices, Big Runtime Effects
This week’s developer writing keeps circling one theme. Small architectural decisions quietly decide whether a system runs fast or grinds to a halt.
Consider the PySpark story from Maithreyan11 on Dev.to. A join across a transactions table and a customer dimension table looked fine on paper.
In practice, 95% of tasks finished in minutes. One task dragged on for 40 minutes while the rest of the cluster sat idle.
The culprit was data skew, a lopsided distribution of join keys across partitions. One partition simply had far more rows to process than the others.
Like PostgreSQL INCLUDE indexes, the fix wasn’t about raw compute power. It was about designing the data layout so work spreads evenly across resources.
Trust Boundaries for AI Agents
Dave Kurian raises a related design problem for AI agents in production apps. As he writes on Dev.to, a model choosing a tool doesn’t make it authorized to run that tool.
Giving an agent one broad function, like a generic runAction call, sounds convenient. It hands too much trust to something that can’t verify its own judgment.
Production systems need explicit permission layers separate from the model’s reasoning. The agent proposes an action; a policy layer decides if it’s actually allowed.
This mirrors the INCLUDE index lesson in a different domain. Separating concerns, key versus payload, reasoning versus authorization, produces safer, faster systems.
Error Handling Deserves the Same Discipline
Antoine Laurent’s piece on REST API error contracts, published in French on Dev.to, makes a similar case. Error responses are part of your API’s contract, not an afterthought.
Teams often document the happy path carefully. Then they let errors fall back to whatever the framework defaults to.
The result is inconsistent formats across endpoints. Some return a 200 status with a hidden success:false flag buried in the body.
Standards like RFC 9457 exist to fix exactly this kind of drift. A consistent error shape helps both automated retries and tired support engineers at 2 a.m.
Real Problem They Solve: Retries Need the Same Precision as PostgreSQL INCLUDE Indexes
Tobias Hoffmann’s article on retry logic and exponential backoff drives the point home further. A failed payment API call at 2 a.m. could mean a network blip, a rate limit, or a crashed server.
Each cause demands a different response. Retry blindly, and you risk charging a customer twice for one transaction.
Done wrong, a 30-second outage can stretch into a 30-minute cascade. Thousands of clients hammering a struggling service only make things worse.
The fix isn’t more retries. It’s smarter, more targeted retries with backoff and jitter built in.
Real Problem They Solve: Takeaways for Builders
Every story here shares a root idea. Precision in design beats brute force in production.
Key lessons worth remembering:
- PostgreSQL INCLUDE indexes cut wasted sorting work inside the B-tree structure.
- Data skew, not raw scale, usually explains slow distributed jobs.
- AI agents need enforced permission layers, not model self-restraint.
- Error contracts and retry logic deserve as much design care as the happy path.
None of these fixes are flashy. They’re the kind of quiet engineering discipline that keeps systems fast and predictable under real-world load.
