Vocabulary for Discussing Database Performance in English

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_id column.”

---

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.

In Practice: Navigating Feedback and Collaboration

Many of the terms we’ve discussed – latency, throughput, bottleneck, query optimization – can feel abstract when you’re trying to communicate them effectively with colleagues, especially if English isn’t your first language. It’s easy to fall into overly technical descriptions that leave others confused or feeling excluded from the conversation. A key difference between good and bad database performance communication lies in framing the issue within a practical context, demonstrating impact rather than just reciting jargon.

Let’s consider a scenario: you’ve been reviewing a pull request introducing a new feature that pulls data from the users table. The developer has written a seemingly straightforward query. However, during your review, you notice a potential problem – a large number of individual queries being executed instead of a single, optimized one. You might not immediately say, “This is an N+1 problem!” Instead, you could start with something more approachable like: “I’m seeing that this query is executing multiple times for each user record. This could lead to significant performance degradation as the number of users grows – potentially impacting page load times and overall application responsiveness.” Follow up by suggesting a solution: “Perhaps we could introduce an index on the user_id column, or restructure the query to perform a single join against the related orders table. Would you be open to exploring those options?” This approach focuses on the effect of the issue – slower page load times – and provides concrete suggestions for improvement.

Another situation might arise in Slack during an incident investigation. A junior developer reports that a particular report is running very slowly. Instead of immediately jumping into explaining concepts like “scan-type execution plan,” they could say, “The report’s taking a long time to generate. I’m seeing high CPU usage on the database server, and the query plan shows it’s doing a full table scan. This means it’s reading every row in the products table – which is quite large. We need to investigate if we can add an index to speed this up.” The key here is to translate technical details into understandable terms for anyone on the team, regardless of their database expertise.

Finally, when writing a PR description explaining changes made to improve query performance, avoid overly complex explanations. A clear and concise statement like: “Optimized the get_user_orders query by adding an index on user_id. This reduces full table scans and significantly improves response times for retrieving user order data.” is far more effective than a lengthy explanation of how the index works or why it’s beneficial.

Here’s an example of using EXPLAIN ANALYZE to investigate a query:

EXPLAIN ANALYZE SELECT * FROM users WHERE id = 123;

This command provides detailed information about how PostgreSQL executes the query, including the number of rows scanned, the execution time for each step, and whether an index was used. Sharing this output – highlighting the “full table scan” – is a powerful way to communicate the problem directly to your team.