Database Capacity Planning Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

Capacity is a measurement with a date

Capacity planning asks whether disk, memory, and connections will still fit after the growth you expect. The size estimator and the growth forecaster turn numbers you supply into a draft. They do not see your database. A number you guessed is labelled as a guess. A number you measured is labelled with the day you measured it.

Disk fills first in the story most admins recognise. Memory and connections are the other two. Write all three, even if one of them is fine. A plan that only talks about disk misses the morning the connection limit is hit.

Growth has a reason: more orders, more logs, a retention change. A percentage with no reason is a decoration. Retention is a decision. Keeping every row forever is a decision you must say out loud.

Licensing, if your engine has it, is a separate sentence and not a purchase this page completes. The calculator does not buy anything. The monitoring guide is how you notice the forecast was wrong.

One database, three numbers, one date

Measure the lab or the production database you administer: size on disk, memory the host has, connections in use at a busy hour you actually saw. Put those three in the ticket with today's date.

Add the growth reason and run the forecaster. If the draft says you run out of disk inside the period you care about, the actions are a retention change, a bigger disk, or an archive. Pick one to investigate. Do not do all three today.

Write the assumption that would make the forecast wrong. If the busy hour was a holiday, say so. A second person should be able to disagree with the assumption without redoing the arithmetic.

Leave a blank where you did not measure. A blank is more honest than a copied number from another system.

A change you can finish

This window produces a forecast and one investigation. Buying disks or changing retention is the next ticket.

Rollback does not apply to a measurement. If you did change a retention setting, the previous value is the rollback, and that was a different window.

Measure size, memory, and connections.
Date each measurement.
Write the growth reason.
Run the forecaster with those inputs.
Mark guesses as guesses.
Choose one follow-up if the forecast is tight.
Hand watching the number to the monitoring guide.

Mistakes that outlive the command

database capacity fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

A forecast with no measurement date.
Someone else's server size used as yours.
Retention of forever, unstated.
Three remedies started at once.
A calculator result treated as a purchase.
Connections ignored because disk looked fine.
A busy-hour number from a quiet Sunday.
No assumption written down.
Personal data copied in to illustrate a row size.
A blank filled with a round number to look finished.

Decisions to write down before the window

One decision for database capacity: Size, memory, and connections are measured or explicitly unknown. Each figure has a date. The growth reason is a sentence. Guesses are marked. The forecast period is named. One follow-up is chosen if space or connections look tight. Retention is stated. No purchase is made from this page. The monitoring guide owns the ongoing number. The performance guide owns a slow statement. This page owns the room it needs. A second person can repeat the assumption. And one database is in the forecast.

The hour you stop

Write the database name, the host, and the clock time before you change anything for database capacity. If this database is serving people and you do not have a copy, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab or a restored copy. The rows you read are rows you are allowed to hold. You do not point a client at a database, a cluster, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a connection string, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.

One change. A config line, an index, a grant, and a restore do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file or the backup you already tested.

A second person reads the scope aloud: which host, which database, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

The lab listens on localhost. 127.0.0.1 is the address you bind until a firewall story exists. example.com is not your host. A generated file that listens on every address is a file you edit before it runs.

Do not run a statement you cannot undo. A delete or a drop without a backup and a where-clause you have read is the mistake this page is here to prevent. Read the statement. Count the rows it will touch. Then decide.

Keep the previous config and the previous dump. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the reload with a second session open when the change can lock you out.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a database nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next database waits until someone else can repeat the proof from the notes. database capacity is done for this window when the proof is written, not when the client printed a prompt.

This page is a planning guide. It is not a vendor manual, not an official standard, and not legal advice. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this database alone until that guide has its own window.

Capacity checks before the forecast is shown to anyone

Confirm this before you call the change done: The three measurements are in the ticket. Dates are next to them. The growth reason is specific. Guesses are labelled. The forecaster inputs match the ticket. Retention is a sentence. Only one follow-up is open. No purchase was made. A second person restated the assumption. No personal rows were copied in. Unknowns are blank, not invented. The database name matches the host you measured. The hostname in the prompt matches the hostname in the ticket for database capacity. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for database capacity happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.