Article of the day

Composite Indexes, Equality-First Ordering & Covering Indexes

Most developers think adding an index automatically makes a query fast. In reality, the order of the indexed columns matters just as much as having the index itself. A poorly ordered composite index can force PostgreSQL to scan thousands of unnecessary entries before finding the rows you actually need.

A composite index stores multiple columns in a specific order. PostgreSQL always starts searching from the leftmost column, so the index should be designed to match how your queries filter data. This is known as the leftmost prefix rule.

When designing composite indexes, always put equality (=) conditions first and range (>, <, BETWEEN) conditions last. Equality filters drastically reduce the search space, allowing PostgreSQL to jump directly to a small subset of rows before scanning the requested range. Reversing this order often results in many unnecessary index scans and filtered rows.

A covering index goes one step further. By using the INCLUDE clause, PostgreSQL stores additional columns inside the index itself. If the query only needs those columns, the database can perform an Index Only Scan, returning results directly from the index without reading the table. This eliminates heap fetches, reduces disk I/O, and significantly improves query performance. For production systems, design indexes around your most frequent query patterns, not around individual columns. Verify every index with EXPLAIN ANALYZE, look for high Rows Removed by Filter, place equality columns before range columns, and use covering indexes for high-traffic read queries to eliminate unnecessary table access.

Read full article 👉 [ LINK ]

@devwitheyob
#TechVibe #ArticleOfTheDay #PostgreSQL #Indexing

brooooooo wth 😭

@selfmadecoder

🚀 Want Free AWS Training? Your Journey Starts This Friday!
We're excited to announce that attendees of our upcoming Cloud Blueprint: Navigating the AWS Solutions Architect Journey & Bootcamp Sneak Peek! session will have the opportunity to join an exclusive AWS Solutions Architect Bootcamp designed for our community.
🎯 What's in it for you?
✅ FREE AWS Solutions Architect Bootcamp training
✅ Access to a temporary AWS cloud environment for hands-on learning and experimentation
✅ Guided learning path and practical cloud experience
✅ Opportunity to learn alongside fellow community members
✅ Support in building real-world AWS skills
📢 Important: Attendance at this Friday's event is a prerequisite for bootcamp eligibility.
If you're serious about building cloud skills, earning AWS certifications, or pursuing a career in cloud computing, this is your opportunity to get started with the support of the AWS User Group Addis Ababa community.
🎙 Featuring: Simon Gebreselassie, Solutions Architect @ AWS
📅 Friday, June 26, 2026
🕕 6:00 PM EAT
💻 Online Event
During the session, we'll discuss the Solutions Architect journey, share details about the bootcamp roadmap, and explain how participants can qualify for the program.
Don't miss the first step toward your cloud career.
👉 Register
@AWSUserGroupAddisAbaba

Lol😂

@devwitheyob
#TechVibe #random

There is a new project on AfterQuery, you just need to upload a repo with good code quality

[ LINK ]

@devwitheyob
#TechVibe #AfterQuery #Jobs

Some people should understand this, fr😭

@devwitheyob
#TechVibe #Gumball

I literally forgot how fun it was watching Cartoon Network growing up.

I'm watching Gumball, and it's fire. I feel like we're the last generation that truly got to experience growing up with cartoons like this before this TikTok era. 😊

@devwitheyob
#TechVibe #nostalgia #cartoon

I think tenant isolation should be enforced in both the application and the database.

The application handles business logic and permissions, but the database should be the last line of defense. If a developer forgets a tenant_id filter or introduces a bug, RLS(Row Level Security) still prevents data from another tenant from being returned. Also every developer has to remember to put that where filter and that is risky

The performance cost of RLS is usually minimal with proper indexing, and the extra security is worth it. Most production SaaS systems use this, application-level authorization + database-level RLS. It's much safer than relying on the application alone.

@devwitheyob
#TechVibe #MultiTenant #databases #Security

Article of the day

Docker layer caching

One of Docker's biggest performance optimizations is layer caching.

Every instruction in a Dockerfile (FROM, COPY, RUN, etc.) creates a new image layer. When you build the image again, Docker doesn't blindly execute every instruction, it checks whether it can reuse previously built layers.

For example, consider this Dockerfile:

FROM node:22

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

CMD ["npm", "start"]

On the first build, Docker executes every instruction. But if you only change server.js and rebuild, Docker reuses all the cached layers up to RUN npm install and only rebuilds the final COPY . . layer. This means your dependencies aren't installed again, making the build significantly faster.

However, if you modify package.json, Docker must rebuild the COPY package*.json layer, the RUN npm install layer, and every layer after them. A change to one layer invalidates that layer and all subsequent layers.

This is why Dockerfile order matters. Place instructions that change rarely (like installing dependencies) near the top, and instructions that change frequently (like copying your application source code) near the bottom. A well-structured Dockerfile can reduce build times from minutes to just a few seconds during development.

Read Full article 👉 [ LINK ]

@devwitheyob
#TechVibe #ArticleOfTheDay #Docker #Caching #DevOps

Who is gonna be my last guest😁

Let's go to 2k🔥

@devwitheyob
#TechVibe #subs

Start reading the terms and conditions when u signing up, guys😁

@devwitheyob
#TechVibe #random

When you're trying to impress with your tech, but it failed😁

@devwitheyob
#TechVibe #random