English for Database Administrators: DBA Communication Vocabulary

Database administrators operate at the intersection of technical precision and cross-team communication. Whether you are coordinating a schema migration with developers, escalating a replication lag incident to management, or presenting a capacity planning report to stakeholders, your ability to communicate clearly in English directly affects how quickly problems get resolved and how much trust you build with your team.

This guide covers the core English vocabulary DBAs use every day — from change management processes to query performance reviews — with real conversation examples you can adapt immediately.

Core Terms: Change Management and Maintenance

Maintenance window — a pre-agreed block of time during which the database can be taken offline or degraded for planned work, without it counting as unplanned downtime.

“We have a two-hour maintenance window scheduled for Saturday night, starting at 01:00 UTC. All non-critical queries should be deferred until after 03:00.”

“Can we fit the index rebuild into the existing maintenance window, or do we need to request a separate slot?”

Change request — a formal document or ticket submitted to request approval for a planned modification to a production system. Often abbreviated to CR or RFC (Request for Change).

“I’ve raised a change request for the tablespace expansion. It’s pending approval from the infrastructure lead and the on-call DBA.”

“Your change request needs a rollback plan before it can go to the CAB for sign-off.”

Rollback plan — a documented procedure describing exactly how to revert a change if it causes problems. No change request should be approved without one.

“Walk me through your rollback plan. If the migration script fails halfway through, what is the exact sequence of steps to restore the previous state?”

“We rolled back to the snapshot taken at 22:45. The rollback plan worked cleanly — total downtime was under eight minutes.”

Schema migration — a controlled change to the database structure, such as adding a column, renaming a table, or modifying constraints. Migrations are applied via migration scripts and must be reviewed carefully.

“The schema migration adds a nullable column first, then backfills data in batches. This approach avoids locking the table during the migration.”

Migration script review language — the phrases DBAs and developers use when examining migration scripts together before applying them to production.

Common expressions in migration script reviews:

“This ALTER TABLE will acquire an exclusive lock — have you considered an online DDL approach?”
“The script doesn’t handle the case where the column already exists. We need an idempotency check.”
“Can you add a transaction wrapper so we can roll back cleanly if the data validation fails?”

Backup Strategy and Recovery Vocabulary

Backup strategy — the overall plan governing how, when, and where database backups are taken. A complete strategy includes three backup types:

Full backup — a complete copy of the entire database at a single point in time. Slowest to create, simplest to restore from.
Incremental backup — captures only the data changed since the last backup of any type. Fastest to create, but restoration requires chaining multiple backups together.
Differential backup — captures all data changed since the last full backup. A middle ground between full and incremental in both size and restore complexity.

“Our current backup strategy runs a full backup every Sunday, differential backups on Wednesday, and incremental backups nightly. Restore time in a worst-case scenario is approximately four hours.”

“The incremental backups are failing silently — we need to audit the backup logs before the next maintenance window.”

Recovery point objective (RPO) — the maximum acceptable amount of data loss, expressed as a time interval. An RPO of one hour means the business can tolerate losing up to one hour of transactions.

“The business has set an RPO of fifteen minutes for the payments database. Our current incremental backup schedule gives us an RPO of four hours — we need to close that gap with transaction log shipping.”

“Before we agree to this architecture, we need the product owner to sign off on the RPO. Otherwise we are making assumptions about acceptable data loss that may not match reality.”

Point-in-time recovery — the ability to restore a database to the exact state it was in at a specific moment, rather than just to the last full backup. Requires continuous transaction log backups.

“A developer accidentally dropped a table at 14:32. I used point-in-time recovery to restore the database to 14:31:50, then exported just the affected table and re-imported it into production.”

“Point-in-time recovery is only possible if your transaction logs are being shipped continuously. If there are gaps in the log chain, recovery to an arbitrary timestamp is not guaranteed.”

Storage, Replication, and Performance Language

Tablespace management language — the vocabulary used when discussing how data is physically organised on disk within the database engine.

Common tablespace phrases:

“The USERS tablespace is approaching its maximum allocated size.”
“We need to add a datafile to the tablespace to accommodate the expected data growth.”
“I would recommend moving the index tablespace to the faster SSD volume to improve query throughput.”

“The database is at 85% storage” — a specific phrasing DBAs use when reporting storage utilisation to non-technical stakeholders. The sentence is deliberately simple so that the urgency is clear without requiring the listener to interpret technical metrics.

“I need to flag this to the team: the database is at 85% storage capacity. At the current growth rate, we will hit the limit in approximately three weeks. I am raising a capacity planning ticket today.”

Capacity planning vocabulary — the language used when forecasting future resource needs and justifying infrastructure investment.

Key phrases:

“Based on the current growth trajectory, we will need an additional 2 TB of storage within the next quarter.”
“I have modelled three scenarios: flat growth, 20% growth, and 40% growth. Even in the conservative scenario, we need to act before the end of the financial year.”
“The capacity plan assumes no major new product launches. If the marketing campaign drives significantly higher write volumes, we should revisit the projections.”

Replication lag communication — the language DBAs use to explain and escalate delays in database replication, where a replica (secondary) database falls behind the primary.

“We are currently seeing replication lag of approximately 45 seconds on the read replica. This means any reads hitting the replica may be returning data that is 45 seconds out of date. If the application requires real-time accuracy, those queries should be redirected to the primary temporarily.”

“The replication lag spiked to eight minutes during the batch import. It has since recovered to under five seconds. I am monitoring it through the rest of the maintenance window.”

Query performance review language — the phrases used during performance review sessions, query tuning discussions, and slow query postmortems.

Common expressions:

“This query is performing a full table scan. We should add a composite index on (customer_id, created_at).”
“The execution plan shows a nested loop join on an unindexed column — that explains the 12-second response time.”
“After adding the index, the query dropped from 8.4 seconds to 120 milliseconds. That is a 98% improvement.”
“Can you run EXPLAIN ANALYSE and share the output? I want to see the actual row estimates versus the planner’s estimates.”

DBA Approval Process

DBA approval process — the formal or informal workflow by which a DBA reviews and authorises changes before they reach production. In most organisations, changes to schema, indexes, stored procedures, or large data migrations require explicit DBA sign-off.

Phrases used during the approval process:

“I am happy to approve this change request, with one condition: the migration must run during the Saturday maintenance window, not during business hours.”
“I cannot approve this script as written. The lack of a rollback plan is a blocker. Please revise and resubmit.”
“This has DBA approval. You are clear to deploy after 02:00 UTC, once the backup has completed successfully.”
“I have reviewed the migration script and have two concerns: the batch size is too large and could cause lock contention, and there is no logging of affected row counts. Please address both before we proceed.”

How to Use These in Conversation

The vocabulary above is most effective when you pair technical precision with context for your audience. A few practical principles:

With developers: Be specific about constraints. Instead of “the query is slow,” say “the query is performing a full table scan on a 200-million-row table. Adding an index on order_status should bring the response time under 50 milliseconds.”

With management: Lead with business impact. Instead of “replication lag is 45 seconds,” say “read queries may return data that is 45 seconds out of date, which could affect order status accuracy in the customer portal.”

In incident calls: Use structured language. State what is happening, what the impact is, and what action you are taking: “The primary database is at 95% storage capacity. New writes are starting to fail. I am extending the tablespace now and will follow up with a capacity planning review tomorrow.”

In change requests: Always include your rollback plan, your estimated impact window, and the DBA approval status before submitting. This reduces back-and-forth and demonstrates professional judgement.

Quick Reference Table

Term	Plain English Meaning
Maintenance window	Pre-agreed downtime slot for planned database work
Change request (CR)	Formal approval ticket for a production change
Rollback plan	Step-by-step procedure to undo a change if it fails
Full / incremental / differential backup	Three backup types differing in scope and restore complexity
RPO (Recovery Point Objective)	Maximum acceptable data loss, expressed in time
Point-in-time recovery	Restoring a database to an exact historical timestamp
Schema migration	A controlled, versioned change to the database structure
Replication lag	Delay between the primary database and its replicas
Capacity planning	Forecasting future storage and compute resource needs
DBA approval	Formal sign-off from the database administrator before a change proceeds