Vocabulary for Discussing Database Performance in English
English vocabulary for database performance: indexes, query plans, N+1 problems, locking, and the phrases engineers use to diagnose and fix slow queries.
When a database slows down, the whole application slows down — so performance conversations come up constantly. They’re full of specialised vocabulary: indexes, query plans, N+1 problems, deadlocks. This guide covers the essential terms, common phrases, and example sentences for discussing database performance confidently in English.
Core Performance Concepts
| Term | Meaning |
|---|---|
| Index | A data structure that speeds up lookups. |
| Query plan | The steps the database takes to run a query. |
| Full table scan | Reading every row (usually slow). |
| Cardinality | The number of distinct values in a column. |
| Latency | How long a query takes to return. |
| Throughput | How many queries per second. |
“This query is doing a full table scan — we need an index on the
user_idcolumn.”
The Language of Slow Queries
- A query can be slow, expensive, or heavy.
- It can hammer the database (send too many requests).
- It can lock rows that others are waiting on.
- It can time out if it runs too long.
“This report query is really expensive — it joins five tables and aggregates millions of rows.”
The word “expensive” refers to resource cost, not money — a key bit of database English.
The Famous N+1 Problem
This comes up so often it deserves its own section.
“We’ve got an N+1 problem here — we’re loading the list, then firing a separate query for each item. That’s a hundred queries instead of one.”
The fix is usually:
“Let’s batch these into a single query with a join, or use eager loading.”
Knowing “N+1”, “batch”, and “eager loading” instantly signals database fluency.
Indexing Vocabulary
- to add / create an index
- a composite index (on multiple columns)
- a covering index (contains all the data the query needs)
- index bloat (an index grown inefficient over time)
- a missing index (one you should have but don’t)
“A composite index on
(status, created_at)would let this filter and sort in one go.”
But indexes have a cost:
“Indexes speed up reads but slow down writes, so we shouldn’t add one for every query.”
Reading the Query Plan
| Phrase | Meaning |
|---|---|
| ”It’s using the index.” | Good — fast lookup. |
| ”It’s doing a sequential scan.” | Reading everything; often slow. |
| ”The estimate is way off.” | The planner’s row estimate is wrong. |
| ”It’s spilling to disk.” | The operation exceeded memory. |
“Let me run EXPLAIN — yep, it’s doing a sequential scan because the index isn’t being used.”
The verb “to EXPLAIN a query” (run the plan analyser) is common engineering shorthand.
Locking and Concurrency
- a lock — a hold on a row or table.
- a deadlock — two transactions each waiting on the other.
- contention — many requests competing for the same resource.
- a long-running transaction — one that holds locks too long.
“We’re seeing lock contention on the orders table during peak hours.” “That deadlock happened because two transactions updated the same rows in different orders.”
Verbs You’ll Use
- to optimise a query
- to profile the database
- to tune the configuration
- to denormalise for read speed
- to shard / partition large tables
- to cache frequent results
“We could denormalise this to avoid the join, but it adds complexity to writes.”
Phrases for Diagnosing Problems
“Where’s the bottleneck — the query, the disk, or the connection pool?” “The slow query log points to this one aggregation.” “Connections are maxed out; we’re queueing requests.” “This got slower as the table grew — it doesn’t scale.”
Words People Confuse
| Confused | Clarification |
|---|---|
| Index vs key | A key enforces uniqueness; an index speeds lookups (often both). |
| Normalise vs denormalise | Normalise removes duplication; denormalise adds it for speed. |
| Latency vs throughput | Latency is per-query speed; throughput is volume. |
| Lock vs deadlock | A lock is normal; a deadlock is a stuck cycle. |
A Sentence to Practise
“This endpoint is slow because of an N+1 problem — we’re firing one query per row. I’d batch them with a join and add a composite index on
(status, created_at). That should turn a hundred queries into one and let it scale.”
If you can say that fluently, you can lead a database performance discussion.
With this vocabulary you can diagnose and discuss almost any database slowdown in English — from spotting a full table scan, to fixing an N+1, to explaining why an index speeds reads but slows writes. Use the example sentences as templates, keep your normalise/denormalise and latency/throughput pairs straight, and you’ll sound like the engineer who actually knows where the bottleneck is.