Anatomy of Database Index Structures: Fundamentals of Query

The Unsung Heroes of Database Performance: Index Structures

Slow database queries are a problem most of us have encountered at least once in our careers. Sometimes it manifests as a report taking 3 hours, other times as an API endpoint making users wait. One of the most significant factors underlying these performance issues is the non-use or misconfiguration of appropriate index structures. In this post, I will delve into the most commonly used index types in PostgreSQL (B-tree, GIN, BRIN) and examine when we should prefer each one with concrete examples. In my 20 years of field experience, I've seen that understanding index structures forms the foundation of query optimization.

While reading EXPLAIN ANALYZE output is one of the first things that comes to mind when discussing query optimization, it's essential to understand the underlying data structure for this output to be meaningful. A database index is essentially like a book index; it allows you to jump directly to the relevant section instead of scanning page by page for the information you're looking for. However, each index type has its own advantages and disadvantages. Index choices made without knowing what data you access and how frequently can degrade performance instead of improving it, and even unnecessarily consume disk space.

B-tree Index: The All-Rounder

The B-tree (Balanced Tree) is the most widely used index structure in modern databases. It offers excellent performance for queries using equality (=) and comparison (>, <, >=, <=) operators. Data is stored in a sorted manner within a tree structure. This allows search operations to have logarithmic time complexity (O(log n)). This means that even as the amount of data increases, the search time grows very slowly. When a query has a condition like WHERE id = 123, we can directly reach the relevant data with a B-tree index.

ℹ️ Advantages of B-tree Index

• High performance for equality and range queries.
• Suitable for general-purpose use.
• Effective in situations requiring ordered data access.

In a production ERP system, adding a B-tree index to the order_date column of the orders table dramatically improves performance when querying for orders within a specific date range (WHERE order_date BETWEEN '2026-01-01' AND '2026-01-31'). Without this index, the database would have to scan the entire table. This situation leads to unacceptably slow performance on tables with millions of rows. For example, on an orders table with approximately 10 million rows, a date range query without an index on order_date might take 5 seconds, whereas with a correctly configured B-tree index, this time can drop to below 50 milliseconds. This creates a massive difference in user experience.

-- Example of creating a B-tree index
CREATE INDEX idx_orders_order_date ON orders (order_date);

-- Example query
SELECT * FROM orders WHERE order_date BETWEEN '2026-01-01' AND '2026-01-31';

B-tree indexes can be created not only for a single column but also for multiple columns (composite index). This is even more effective in queries like WHERE column1 = 'A' AND column2 > 100. However, the order of columns is important here. Generally, columns with higher selectivity (containing more distinct values) should be placed first.

GIN Index: Ideal for Text Search and JSON Data

GIN (Generalized Inverted Index) is preferred, especially when working with text search (tsvector, tsquery) and complex data types like JSONB. A GIN index stores a list of rows corresponding to each value. For example, for every word found in the content of a blog post, an index entry is created showing which posts that word appears in. This structure makes full-text search queries very fast.

⚠️ Disadvantages of GIN Index

• Occupies more disk space than B-tree.
• Data insertion, deletion, and update operations are slower than B-tree.
• Not suitable for ordered or range queries.

The GIN index plays a critical role in search queries performed on product descriptions of an e-commerce site. When a user searches for "blue denim jeans," the database can find the relevant products in seconds thanks to the GIN index. If a GIN index were not used, every search query would have to scan all product descriptions, which would be an incredibly slow process for millions of products. In a financial analysis tool I developed, I significantly sped up complex queries by using GIN indexes on jsonb columns when users analyzed various financial text inputs.

Creating a GIN index in PostgreSQL often involves operator classes like gin_trgm_ops. These operators are optimized for finding similarities or exact matches between texts.

-- Example of creating a GIN index (PostgreSQL 12+)
CREATE INDEX idx_products_description_gin ON products USING GIN (to_tsvector('english', description));

-- Full-text search query
SELECT * FROM products WHERE to_tsvector('english', description) @@ to_tsquery('english', 'blue & denim & jeans');

GIN indexes are also very useful when working with JSONB data. For instance, if an order details table has a jsonb column named items, and you query for product IDs or quantities within this column, a GIN index will speed up these queries.

BRIN Index: A Lightweight Option for Large and Ordered Data

BRIN (Block Range Index) is an index type that takes up less space than B-tree and GIN indexes but can be quite effective under certain conditions. A BRIN index indexes ranges of data blocks. That is, an index entry stores the minimum and maximum values of values within a specific data block range. This index performs best when the data is physically ordered. For example, it's effective for time-series data or geographical location data that are naturally ordered or grouped.

💡 Use Cases for BRIN Index

• Time-series data (ordered by timestamp).
• Geographical location data (geographically grouped).
• Other situations where data is physically ordered.

Consider sensor data collected on an IoT platform. This data is typically written to disk in chronological order. In such cases, a BRIN index added to the timestamp column uses significantly less disk space than a B-tree for querying data within a specific time range and can offer similar performance. For example, on a sensor database with 1 billion rows, adding a B-tree index to the timestamp column might occupy hundreds of megabytes, while a BRIN index might only take up a few megabytes. This is a significant advantage, especially in environments where storage costs are high.

-- Example of creating a BRIN index
CREATE INDEX idx_sensor_data_timestamp_brin ON sensor_data USING BRIN (timestamp);

-- Example query (time range)
SELECT * FROM sensor_data WHERE timestamp BETWEEN '2026-05-21 00:00:00' AND '2026-05-21 23:59:59';

However, if the data is not physically ordered, the effectiveness of a BRIN index is greatly reduced. For instance, if data is frequently inserted and deleted and not kept in an ordered manner, the minimum and maximum values within the same data block will not be very close to each other. This causes the index to scan more data blocks during a search. Therefore, it's important to be aware of the physical ordering of the data before using a BRIN index.

Trade-offs and Considerations in Index Selection

Index selection is not just about performance improvement; it also involves factors such as disk space usage, data insertion/update/deletion (DML) speeds, and maintenance costs. Every index imposes an additional burden on the database.

🔥 Index Management Risks

• Disk Space: Indexes can consume significant amounts of disk space. Too many indexes increase storage costs.
• DML Performance: Every index must be updated during INSERT, UPDATE, and DELETE operations. This slows down DML operations.
• Maintenance: Indexes may need to be rebuilt (reindex) or optimized (vacuum).

In an enterprise software development project, there can be an initial tendency to add an index to every query. However, over time, it becomes apparent that so many indexes make data entry incredibly slow. For example, updating multiple indexes when registering a user can extend the operation from seconds to tens of seconds. At this point, regularly checking system tables like pg_stat_user_indexes and removing unused indexes to determine which indexes are truly necessary is critical.

Furthermore, it's necessary to consider the overall workflow of the application, not just query performance. In an ERP system, indexes optimized for reporting queries can negatively affect the performance of data entry screens. Therefore, the best approach is to address both read (SELECT) and write (INSERT, UPDATE, DELETE) operations in a balanced manner. Analyzing the EXPLAIN ANALYZE output under different application scenarios, not just on a per-query basis, is important.

Advanced Tips for Query Optimization

After understanding the fundamentals of index structures, we can take more advanced steps for query optimization. One of these is understanding the behavior of PostgreSQL's query planner and providing hints when necessary. The ANALYZE command helps the planner make better decisions by updating statistics.

The pg_stat_statements module is a great resource for identifying the most used and slowest queries. By enabling this module, you can see which queries need optimization the most. This allows you to focus your resources on areas that will provide the most benefit. For example, in a financial calculator application, optimizing the top 10 most frequently used queries can improve the overall performance of the application by more than 30%.

💡 Additional Tips for Query Optimization

• `ANALYZE` Command: Improves the query planner by updating statistics.
• `pg_stat_statements`: Identifies the slowest and most frequently used queries.
• Composite Indexes: Indexes involving multiple columns can speed up complex queries.
• Partial Indexes: Saves disk space and improves performance by creating indexes for rows that meet a specific condition.

It's important to remember that indexes are not magic wands. Sometimes the root of the problem lies not in the index structure but in the database design, poorly written SQL queries, or insufficient hardware resources. Therefore, it's important to conduct a comprehensive analysis and accept that the problem may not be reducible to a single cause. When solving performance issues encountered in an Android spam blocking application, a side project I developed, index optimization was only one part; I achieved the real improvements by redesigning the data model.

Conclusion: Taking Performance to the Peak with Index Structures

Database index structures are the cornerstone of query performance. Knowing when and how to use different index types like B-tree, GIN, and BRIN is a critical skill for database administrators and developers. The right index selection can multiply query speed, improve user experience, and reduce infrastructure costs.

Each of the index types we examined in this post has its own unique advantages and disadvantages. While B-tree is a standard choice for general-purpose queries, GIN is ideal for text and unstructured data, and BRIN is ideal for ordered data. When making index selections, it's important to consider not only read performance but also DML operations and disk space usage. Remember, the best index is the index you need; neither more nor less.

In summary, optimizing database performance is an ongoing process. Regularly analyzing query plans, keeping statistics up-to-date, and cleaning up unused indexes are vital for the health of your system. With this knowledge, I believe you can unlock the full potential of your databases.