Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

The short version: four things run out on Salesforce, and they run out on different schedules. Data storage grows slowly and predictably. File storage grows faster than anyone models. API calls spike with an integration change. Async executions spike with a data load. Plan each separately, because the warning signs differ and only one of them is on a dashboard anybody looks at.

Data storage

Most objects cost a flat amount per record regardless of how many fields are populated, so storage is a record count problem rather than a field count problem. Adding thirty fields to Account costs nothing. Adding four million Task records costs a great deal.

The growth is usually predictable because it comes from a process: cases created per week, orders per month, activity logging per user per day. Take the top five objects by count, work out the weekly rate, and project it. The result is either comfortable for years or alarming, and there is rarely a middle.

SELECT COUNT(Id) FROM Task WHERE CreatedDate = LAST_N_DAYS:7

Run that per object and multiply. It takes ten minutes and it is more accurate than any estimate.

File storage, which is the one that surprises people

File storage has its own allowance and its own growth curve, and the curve is driven by behaviour rather than by process. One team deciding to attach PDFs to every case changes the trajectory in a week.

Versions compound it. A file uploaded ten times holds ten versions and consumes ten times the space, with nothing pruning them. The equivalent check is Setup, Storage Usage, and the list of largest files, which is usually surprising the first time anyone looks.

API calls

The daily allowance comes from your edition and licence count. Consumption comes from integrations, and integration consumption is stepwise rather than gradual: it sits flat for months and then a middleware change doubles it overnight.

Which means trend analysis is less useful here than a headroom rule. Know what percentage you use on a normal day, and treat anything above 50 per cent as needing attention before the next integration is added, not after. The monitoring detail is in monitoring API consumption.

Async executions

The daily asynchronous Apex limit covers future, queueable, batch and scheduled together. A normal day uses a fraction of it. A data migration or a mass recalculation can use most of it in an afternoon, and everything else async in the org then fails.

The planning move is to treat any bulk operation as a capacity event: check the current day’s consumption before starting, and schedule large jobs when nothing else needs the allowance.

What to do before you buy more

Extra storage is available and it is not cheap. Three things usually recover more than they cost:

  • Delete what is genuinely dead. Records from a migration that was rerun, test data in production, integration logs from 2021. The recycle bin holds them for 15 days, so this is reversible for long enough to be safe.
  • Archive to a big object or outside the platform. Big objects have a much lower per-record cost and are queryable, with restrictions. Suitable for anything you must keep and rarely read.
  • Prune file versions. Often the largest single recovery, and nobody misses version four of a document that has fifteen.

Set the alarm where it helps

Storage warnings fire at a threshold you can set. Set it at 70 per cent, not the default, because recovering storage takes weeks of decisions and approvals rather than an afternoon. API notifications should be lower still.

Put both somewhere a person reads. A notification that arrives in a shared mailbox with an inbox rule is a notification that does not exist.

Frequently asked

Does deleting records free storage immediately? Not until the recycle bin is emptied or 15 days pass. Plan for the lag.

Do sandboxes count? They have their own allowances, generally smaller. A Full sandbox matches production storage, which is a cost consideration on its own.

What consumes the most per record? Usually high-volume transactional objects: Task, EmailMessage, and whatever custom object your integration writes to. Field history is easy to forget and accumulates quietly.