Database Capacity Planning — Vocabulary and Communication
Learn vocabulary for database capacity planning: growth projections, storage tiers, connection limits, and scaling decisions.
0 / 29 completed
1 / 29
What is 'connection limit' in database capacity planning?
Databases have a max_connections limit (PostgreSQL default: 100, configurable). Each connection uses memory (5–10MB). At connection limit, new connections fail immediately. Solutions: connection pooling (PgBouncer reduces connections to database), increasing the limit (requires more RAM), or connection management in the application.
2 / 29
What is 'table bloat' in database capacity planning?
In PostgreSQL's MVCC model, UPDATE and DELETE leave dead row versions in the table. VACUUM reclaims space logically (marks dead space reusable) but does not return space to the OS unless VACUUM FULL is run (which locks the table). Bloat monitoring is essential for capacity planning.
3 / 29
What is 'IOPS' in database infrastructure vocabulary?
IOPS (Input/Output Operations Per Second) measures how many read/write operations a storage system can handle per second. OLTP databases are typically IOPS-bound (many small random reads/writes). Database capacity planning requires estimating peak IOPS from the workload and selecting storage that can sustain them.
4 / 29
What is 'vertical scaling' vs. 'horizontal scaling' in database vocabulary?
Vertical scaling (scale up): add CPU cores, RAM, faster NVMe — easy but limited by single-server maximums and expensive at the top end. Horizontal scaling (scale out): add read replicas for read traffic, shard writes across multiple nodes — more complex but theoretically unlimited.
5 / 29
What is a 'storage tier' decision in database capacity planning?
Storage tiers in databases: hot tier (NVMe SSD — highest IOPS, highest cost — for active transactional data), warm tier (SATA SSD — moderate IOPS/cost), cold tier (HDD/object storage — lowest cost — for archived data rarely queried). Choosing correctly reduces costs while maintaining required performance.
6 / 29
PR Description
Subject: Database Performance Degradation - User Profile Service
During code review, Sarah flagged a potential bottleneck in the user profile service. She noted that 'query latency' was spiking significantly during peak hours and suggested we investigate database capacity.
Which of the following phrases best describes what Sarah *should* have included to effectively communicate this issue to the team and justify further investigation?
options
A) "The database is experiencing high CPU utilization, which needs immediate optimization."
B) "We need to increase the number of database servers to handle more requests. Let's scale up!"
C) "Query latency has increased significantly during peak hours, indicating a potential capacity issue that warrants deeper analysis of database performance metrics and resource constraints."
D) "The database is slow because we have too many users; we need to limit access." This question tests understanding of how developers discuss database capacity problems. Option A focuses on a symptom (CPU utilization), not the root cause – it's a common misinterpretation. Option B suggests scaling servers without considering the underlying problem, which is often inefficient. Option C correctly identifies 'query latency' as a key metric and frames the issue as a potential 'capacity issue,' emphasizing the need to analyze performance data and resource constraints, aligning with a professional developer's communication style. Option D incorrectly attributes slowness to user volume, ignoring database infrastructure factors.
7 / 29
PR Description
Subject: Database Performance Degradation - User Profile Service
During code review, Sarah flagged a potential bottleneck in the user profile service. She noted that 'query latency' was spiking significantly during peak hours and suggested we investigate database capacity.
Which of the following phrases best describes what Sarah *should* have included to effectively communicate this issue to the team and justify further investigation?
options
A) "The database is experiencing high CPU utilization, which needs immediate optimization."
B) "We need to increase the number of database servers to handle more requests. Let's scale up!"
C) "Query latency has increased significantly during peak hours, indicating a potential capacity issue that warrants deeper analysis of database performance metrics and resource constraints."
D) "The database is slow because we have too many users; we need to limit access." This question tests understanding of how developers discuss database capacity problems. Option A focuses on a symptom (CPU utilization), not the root cause – it's a common misinterpretation. Option B suggests scaling servers without considering the underlying problem, which is often inefficient. Option C correctly identifies 'query latency' as a key metric and frames the issue as a potential 'capacity issue,' emphasizing the need to analyze performance data and resource constraints, aligning with a professional developer's communication style. Option D incorrectly attributes slowness to user volume, ignoring database infrastructure factors.
8 / 29
PR Description
Subject: Database Performance Degradation - User Profile Service
During code review, Sarah flagged a potential bottleneck in the user profile service. She noted that 'query latency' was spiking significantly during peak hours and suggested we investigate database capacity.
Which of the following phrases best describes what Sarah *should* have included to effectively communicate this issue to the team and justify further investigation?
options
A) "The database is experiencing high CPU utilization, which needs immediate optimization."
B) "We need to increase the number of database servers to handle more requests. Let's scale up!"
C) "Query latency has increased significantly during peak hours, indicating a potential capacity issue that warrants deeper analysis of database performance metrics and resource constraints."
D) "The database is slow because we have too many users; we need to limit access." This question tests understanding of how developers discuss database capacity problems. Option A focuses on a symptom (CPU utilization), not the root cause – it's a common misinterpretation. Option B suggests scaling servers without considering the underlying problem, which is often inefficient. Option C correctly identifies 'query latency' as a key metric and frames the issue as a potential 'capacity issue,' emphasizing the need to analyze performance data and resource constraints, aligning with a professional developer's communication style. Option D incorrectly attributes slowness to user volume, ignoring database infrastructure factors.
9 / 29
PR Description
Subject: Database Performance Degradation - User Profile Service
During code review, Sarah flagged a potential bottleneck in the user profile service. She noted that 'query latency' was spiking significantly during peak hours and suggested we investigate database capacity.
Which of the following phrases best describes what Sarah *should* have included to effectively communicate this issue to the team and justify further investigation?
options
A) "The database is experiencing high CPU utilization, which needs immediate optimization."
B) "We need to increase the number of database servers to handle more requests. Let's scale up!"
C) "Query latency has increased significantly during peak hours, indicating a potential capacity issue that warrants deeper analysis of database performance metrics and resource constraints."
D) "The database is slow because we have too many users; we need to limit access." This question tests understanding of how developers discuss database capacity problems. Option A focuses on a symptom (CPU utilization), not the root cause – it's a common misinterpretation. Option B suggests scaling servers without considering the underlying problem, which is often inefficient. Option C correctly identifies 'query latency' as a key metric and frames the issue as a potential 'capacity issue,' emphasizing the need to analyze performance data and resource constraints, aligning with a professional developer's communication style. Option D incorrectly attributes slowness to user volume, ignoring database infrastructure factors.
10 / 29
David in the standup meeting said, "We're seeing a lot of requests hitting our user data database. I'm concerned about capacity. What does 'throughput' refer to in this context?"Throughput describes the *volume* of work a system handles over a period. In this case, it's about how many user requests the database can process simultaneously—a key factor in capacity planning. Options A and D are related to cost or storage, while option C focuses on latency, not overall volume.
11 / 29
Maria sent this Slack message: 'The `orders` table is growing rapidly. I'm worried about performance. What does 'table fragmentation' most likely indicate?'.Table fragmentation happens when data gets scattered across non-contiguous blocks on the storage device. This forces the database to perform more I/O operations to retrieve rows, significantly slowing down queries—the core issue Maria is raising. Options A and D describe other phenomena, while option C represents table optimization.
12 / 29
Ben in the code review comments on a new service: 'The API response time for retrieving user details is consistently high. What metric should we investigate first to understand the root cause?'Query latency is the primary measurement for assessing response times. While other metrics (CPU, storage) might be contributing factors, latency directly reflects how long a single query takes to execute – this is what Ben should prioritize investigating as the immediate cause of the high API response time. Options A and D are irrelevant to direct query performance.
13 / 29
Chloe is discussing database scaling strategies in a team meeting. She says, 'We need to ensure we can handle peak loads without significant performance degradation. Which approach would generally provide the *most* immediate capacity increase?'.Horizontal scaling (adding more servers) typically provides the quickest way to increase capacity—you can distribute the load across multiple machines. Vertical scaling (increasing resources on a single server) has limitations and downtime. While sharding is useful for large datasets, it's a much more complex undertaking than simply adding more instances. Optimizing queries improves efficiency but doesn't directly scale capacity.
14 / 29
Frank writes in the PR description: 'To reduce storage costs, we're moving infrequently accessed data to a cheaper archive tier. What does 'data tiering' primarily address?'.Data tiering is about strategically placing data based on access frequency and cost. Less frequently accessed data can be moved to a lower-cost storage tier (like archive) without significantly impacting performance for the most critical operations—this is what Frank's description highlights.
15 / 29
David in the standup meeting said, "We're seeing a lot of requests hitting our user data database. I'm concerned about capacity. What does 'throughput' refer to in this context?"Throughput describes the *volume* of work a system handles over a period. In this case, it's about how many user requests the database can process simultaneously—a key factor in capacity planning. Options A and D are related to cost or storage, while option C focuses on latency, not overall volume.
16 / 29
Maria sent this Slack message: 'The `orders` table is growing rapidly. I'm worried about performance. What does 'table fragmentation' most likely indicate?'.Table fragmentation happens when data gets scattered across non-contiguous blocks on the storage device. This forces the database to perform more I/O operations to retrieve rows, significantly slowing down queries—the core issue Maria is raising. Options A and D describe other phenomena, while option C represents table optimization.
17 / 29
Ben in the code review comments on a new service: 'The API response time for retrieving user details is consistently high. What metric should we investigate first to understand the root cause?'Query latency is the primary measurement for assessing response times. While other metrics (CPU, storage) might be contributing factors, latency directly reflects how long a single query takes to execute – this is what Ben should prioritize investigating as the immediate cause of the high API response time. Options A and D are irrelevant to direct query performance.
18 / 29
Chloe is discussing database scaling strategies in a team meeting. She says, 'We need to ensure we can handle peak loads without significant performance degradation. Which approach would generally provide the *most* immediate capacity increase?'.Horizontal scaling (adding more servers) typically provides the quickest way to increase capacity—you can distribute the load across multiple machines. Vertical scaling (increasing resources on a single server) has limitations and downtime. While sharding is useful for large datasets, it's a much more complex undertaking than simply adding more instances. Optimizing queries improves efficiency but doesn't directly scale capacity.
19 / 29
Frank writes in the PR description: 'To reduce storage costs, we're moving infrequently accessed data to a cheaper archive tier. What does 'data tiering' primarily address?'.Data tiering is about strategically placing data based on access frequency and cost. Less frequently accessed data can be moved to a lower-cost storage tier (like archive) without significantly impacting performance for the most critical operations—this is what Frank's description highlights.
20 / 29
David in the standup meeting said, "We're seeing a lot of requests hitting our user data database. I'm concerned about capacity. What does 'throughput' refer to in this context?"Throughput describes the *volume* of work a system handles over a period. In this case, it's about how many user requests the database can process simultaneously—a key factor in capacity planning. Options A and D are related to cost or storage, while option C focuses on latency, not overall volume.
21 / 29
Maria sent this Slack message: 'The `orders` table is growing rapidly. I'm worried about performance. What does 'table fragmentation' most likely indicate?'.Table fragmentation happens when data gets scattered across non-contiguous blocks on the storage device. This forces the database to perform more I/O operations to retrieve rows, significantly slowing down queries—the core issue Maria is raising. Options A and D describe other phenomena, while option C represents table optimization.
22 / 29
Ben in the code review comments on a new service: 'The API response time for retrieving user details is consistently high. What metric should we investigate first to understand the root cause?'Query latency is the primary measurement for assessing response times. While other metrics (CPU, storage) might be contributing factors, latency directly reflects how long a single query takes to execute – this is what Ben should prioritize investigating as the immediate cause of the high API response time. Options A and D are irrelevant to direct query performance.
23 / 29
Chloe is discussing database scaling strategies in a team meeting. She says, 'We need to ensure we can handle peak loads without significant performance degradation. Which approach would generally provide the *most* immediate capacity increase?'.Horizontal scaling (adding more servers) typically provides the quickest way to increase capacity—you can distribute the load across multiple machines. Vertical scaling (increasing resources on a single server) has limitations and downtime. While sharding is useful for large datasets, it's a much more complex undertaking than simply adding more instances. Optimizing queries improves efficiency but doesn't directly scale capacity.
24 / 29
Frank writes in the PR description: 'To reduce storage costs, we're moving infrequently accessed data to a cheaper archive tier. What does 'data tiering' primarily address?'.Data tiering is about strategically placing data based on access frequency and cost. Less frequently accessed data can be moved to a lower-cost storage tier (like archive) without significantly impacting performance for the most critical operations—this is what Frank's description highlights.
25 / 29
David in the standup meeting said, "We're seeing a lot of requests hitting our user data database. I'm concerned about capacity. What does 'throughput' refer to in this context?"Throughput describes the *volume* of work a system handles over a period. In this case, it's about how many user requests the database can process simultaneously—a key factor in capacity planning. Options A and D are related to cost or storage, while option C focuses on latency, not overall volume.
26 / 29
Maria sent this Slack message: 'The `orders` table is growing rapidly. I'm worried about performance. What does 'table fragmentation' most likely indicate?'.Table fragmentation happens when data gets scattered across non-contiguous blocks on the storage device. This forces the database to perform more I/O operations to retrieve rows, significantly slowing down queries—the core issue Maria is raising. Options A and D describe other phenomena, while option C represents table optimization.
27 / 29
Ben in the code review comments on a new service: 'The API response time for retrieving user details is consistently high. What metric should we investigate first to understand the root cause?'Query latency is the primary measurement for assessing response times. While other metrics (CPU, storage) might be contributing factors, latency directly reflects how long a single query takes to execute – this is what Ben should prioritize investigating as the immediate cause of the high API response time. Options A and D are irrelevant to direct query performance.
28 / 29
Chloe is discussing database scaling strategies in a team meeting. She says, 'We need to ensure we can handle peak loads without significant performance degradation. Which approach would generally provide the *most* immediate capacity increase?'.Horizontal scaling (adding more servers) typically provides the quickest way to increase capacity—you can distribute the load across multiple machines. Vertical scaling (increasing resources on a single server) has limitations and downtime. While sharding is useful for large datasets, it's a much more complex undertaking than simply adding more instances. Optimizing queries improves efficiency but doesn't directly scale capacity.
29 / 29
Frank writes in the PR description: 'To reduce storage costs, we're moving infrequently accessed data to a cheaper archive tier. What does 'data tiering' primarily address?'.Data tiering is about strategically placing data based on access frequency and cost. Less frequently accessed data can be moved to a lower-cost storage tier (like archive) without significantly impacting performance for the most critical operations—this is what Frank's description highlights.
Frequently Asked Questions
What does the "Database Capacity Planning — Vocabulary and Communication" exercise practise?
Learn vocabulary for database capacity planning: growth projections, storage tiers, connection limits, and scaling decisions.
How many questions are in this exercise?
This exercise has 29 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Database Optimization category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Database Capacity Planning — Vocabulary and Communication" part of a larger series?
Yes — it's one exercise in the Database Optimization category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Database Optimization category page for related exercises, or browse the main Exercises hub for other IT English topics.