[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-index-database::en":3,"gloss-cluster-index-database::en":20,"gloss-next-index-database::en":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"index-database","data-infra","Index (Database)","A database index is an auxiliary data structure — typically a B-tree or similar sorted structure — built on one or more columns of a table to make lookups on those columns dramatically faster than scanning every row. Without an index, finding a specific row (`WHERE email = 'user@example.com'`) requires the database to check every single row in the table (a \"sequential scan\" or \"table scan\") — fine for a few hundred rows, ruinous for a few million. Why it matters for AI\u002FSaaS builders: indexing is one of the highest-leverage, lowest-effort performance interventions available, and its absence is a leading cause of the classic \"the app got slow as we grew\" complaint. It's distinct from — but conceptually related to — the \"index\" a vector database builds over embeddings (an embedding index): both trade write overhead and extra storage for faster reads, just over very different kinds of data and using very different underlying structures (B-trees for exact\u002Frange matches on scalar values, HNSW\u002FIVFFlat for approximate similarity over high-dimensional vectors). How it works: a typical B-tree index keeps column values in sorted order alongside a pointer back to the full row, so the database can binary-search to the matching value instead of scanning linearly — turning an O(n) lookup into roughly O(log n). Indexes should be added on columns frequently used in `WHERE` clauses, `JOIN` conditions, and `ORDER BY` clauses — but not indiscriminately, because every index adds overhead to every `INSERT`\u002F`UPDATE`\u002F`DELETE` (the index itself must be updated too) and consumes additional disk space; over-indexing a write-heavy table is a real and common mistake. Composite indexes (spanning multiple columns, e.g., `(customer_id, created_at)`) speed up queries filtering or sorting on that exact combination but are less useful for queries touching only the second column alone, due to how B-tree ordering works — a subtlety that trips up a lot of query-optimization work. Worked example: a multi-tenant SaaS's `events` table grows to 40 million rows; a dashboard query filtering `WHERE customer_id = ? AND created_at > ?` starts taking 6+ seconds as a sequential scan. Adding a composite index `CREATE INDEX idx_events_customer_created ON events (customer_id, created_at);` drops that same query to under 10ms, because Postgres can now jump directly to the relevant rows for that customer and time range instead of reading the entire table on every dashboard load. The team also runs `EXPLAIN ANALYZE` on the query before and after to confirm the query planner actually chose to use the new index rather than ignoring it — a step worth normalizing, since an index that exists but isn't being used (a common outcome of poor column ordering in a composite index) provides zero benefit while still paying its full write-time cost.","A database index is a data structure that speeds up lookups on specific columns, trading extra storage and write overhead for much faster reads.",null,[11,14,17],{"slug":12,"name":13},"embedding-index","Embedding Index",{"slug":15,"name":16},"postgresql","PostgreSQL",{"slug":18,"name":19},"sharding","Sharding",[21,25,28,31,34,38,41,44,47,50,54,57],{"slug":22,"category":5,"name":23,"updated_at":24},"acid","ACID","2026-08-24T02:46:37+00:00",{"slug":26,"category":5,"name":27,"updated_at":24},"ann-search","ANN Search",{"slug":29,"category":5,"name":30,"updated_at":24},"backpressure","Backpressure",{"slug":32,"category":5,"name":33,"updated_at":24},"batch-processing","Batch Processing",{"slug":35,"category":5,"name":36,"updated_at":37},"bm25","BM25","2026-08-24T02:46:38+00:00",{"slug":39,"category":5,"name":40,"updated_at":24},"cache","Cache",{"slug":42,"category":5,"name":43,"updated_at":24},"cap-theorem","CAP Theorem",{"slug":45,"category":5,"name":46,"updated_at":24},"change-data-capture","Change Data Capture (CDC)",{"slug":48,"category":5,"name":49,"updated_at":24},"chroma","Chroma",{"slug":51,"category":5,"name":52,"updated_at":53},"chunk-overlap","Chunk Overlap","2026-08-24T03:30:02+00:00",{"slug":55,"category":5,"name":56,"updated_at":24},"columnar-storage","Columnar Storage",{"slug":58,"category":5,"name":59,"updated_at":24},"connection-pooling","Connection Pooling"]