Data Storage in Folio
Salesforce charges roughly 2 KB per record for custom objects, regardless of how many fields are populated or how much text they contain. A Folio Document with 50,000 characters of body text consumes the same ~2 KB as an empty one. Long text area fields do not increase data storage consumption.
How Salesforce charges for Folio records
Salesforce sizes data storage per record, not per byte, and gives ~2 KB as the estimate for most standard and custom object records.
A few standard objects are documented exceptions to that rate. None of them are custom objects, so none of them apply to Folio. Every object Folio creates is a custom object governed by the flat ~2 KB per record rule.
Length makes no difference. A one-line note, a 20-page account plan, and the longest document Folio can hold are all charged the same ~2 KB. Storage is driven by record count, not content, which is why the retention settings are the control that matters.
See Salesforce’s record size overview and estimated record size by object.
Does a managed package change anything?
No. Folio’s objects are second-generation (2GP) managed package custom objects and consume data storage identically to custom objects built in-house. There is no ISV surcharge, no separate allocation, and no different accounting.
How much storage Folio uses
Model assumptions
These are illustrative assumptions, not measured values. Substitute your own and re-run the arithmetic.
| Assumption | Value |
|---|---|
| Enterprise Edition allocation | 10 GB base + 20 MB per user license |
| Per record | ~2 KB |
| Version snapshots per actively edited Document | ~20 |
| Version retention window | 18 months (conservative; default is 12) |
| Comments per Document | ~3 |
| Junctions per Document | 1 |
| Stars per Document | ~0.33 |
| View Preferences per Document | ~2 |
| Folio Log overhead | ~10% |
| Horizon | 3 years |
Documents and comments accumulate indefinitely. Version records roll off at whatever Document Version Retention is set to, so they only ever represent the most recent window of editing activity.
This model assumes an 18-month window, which is deliberately conservative — the shipped default is 12 months, and a shorter window means fewer records. Over a 3-year horizon an 18-month window leaves roughly half the Documents still carrying versions, averaging about 10 version records per Document.
1 Document + 10 versions + 3 comments + 1 junction + 0.33 stars + 2 View Preferences ≈ 17.3 records, plus ~10% for logging ≈ 19 records, or about 38 KB per Document.
Usage tiers
| Tier | Documents per user per year | Per user over 3 years |
|---|---|---|
| Light | 15 | ~1.7 MB |
| Typical | 40 | ~4.6 MB |
| Heavy | 100 | ~11.4 MB |
Share of Enterprise Edition allocation
Two separate numbers drive this. Allocation is granted per Salesforce user license, across the whole org. Consumption comes only from Folio-licensed users. Orgs above a few hundred seats rarely license Folio to everyone, so the two rarely match.
The table below models that. Folio seat counts are illustrative — substitute your own.
| Salesforce users | Folio seats | Light | Typical | Heavy |
|---|---|---|---|---|
| 50 | 50 | ~1% | 2% | 5% |
| 100 | 100 | ~1.5% | ~4% | ~9% |
| 500 | 250 | ~2% | ~6% | ~14% |
| 1,000 | 400 | ~2% | ~6% | ~15% |
| 2,000 | 500 | ~2% | ~5% | ~11% |
Percentages are of total Enterprise Edition data storage allocation. The Heavy column models every Folio user creating 100 Documents a year for three years, and is the high end of the range rather than an expectation.
Allocation is a fixed 10 GB base plus a linear per-user increment, while Folio consumption is purely linear and applies only to Folio seats. Both effects favor larger orgs, which is why the percentages flatten rather than climbing with headcount.
If Folio is licensed to every Salesforce user, the percentages rise. A 1,000-seat org with 1,000 Folio seats at Heavy usage reaches roughly 38%, and a 2,000-seat org about 45%. That combination — org-wide licensing at sustained heavy authoring — is the genuine worst case.
Version records are roughly two-thirds of all records Folio creates.
The usage tiers are Folio’s own model. No credible public benchmark exists for documents created per employee per year.
Will you need to buy more storage?
Almost certainly not.
At ~2 KB per record, 1 GB holds roughly 500,000 records. At ~19 records per Document, reaching 5 GB would take about 138,000 Documents — 1,380 per person in a 100-user org. Folio is very unlikely to be what pushes an org past its allocation.
If you ever do need additional data storage, pricing depends on your contract. Your Salesforce account executive can give you accurate figures for your org.
Images in Documents
Images are the exception to the per-record model.
Images count against file storage at actual size. An image uploaded into a Document is stored as a Salesforce ContentDocument record. It counts against file storage rather than data storage, and file storage is charged by byte size — a 2 MB screenshot consumes 2 MB.
File storage allocations are more generous. Enterprise, Performance, and Unlimited receive 10 GB base plus 2 GB per user. For a 50-user Enterprise org that is 110 GB, or roughly 56,000 images at 2 MB each. See Salesforce Files storage allocations.
Removed images are cleaned up. An asynchronous job deletes the underlying file when an image is removed from a Document, usually within five minutes. Because the cleanup runs asynchronously, storage usage does not drop the instant the image is deleted.
Import and export files
Import and export both use Salesforce ContentDocuments as their transport, so both consume file storage rather than data storage. Both also ship with cleanup, so the files don’t accumulate. For how the feature itself works, see Admin Panel — Migration.
Importing
When you import .docx or Markdown files, each uploaded file is stored as a ContentDocument, then processed and converted into a Folio Document record.
The import screen has an After import: Delete the uploaded files checkbox. Select it and successfully converted uploads are removed once they’ve become Folio Documents, so the org doesn’t hold a copy of every document in file storage as well as data storage.
Files that fail to convert are kept even with the checkbox selected. Failures are rare, but the source file is retained rather than deleted so you can investigate and retry.
Exporting
Exporting from the Export tab processes Folio Documents into the target file type in batches, compresses them into zip files, and stores those zips as ContentDocuments.
Document Export Retention in the Admin Panel’s Data Retention settings purges export zips automatically after the configured period. The default is 6 months, and it’s admin-configurable.
Export archives are the kind of file that would otherwise sit in your org indefinitely after being created once for a migration. The retention setting handles that without anyone having to remember.
Which objects grow fastest
Folio ships retention controls for the objects that accumulate. All are in the Data Retention section of the Admin Panel’s Settings tab.
| Field | Default | Controls |
|---|---|---|
| Notification Retention | 6 months | How long Folio notifications are kept |
| Document Export Retention | 6 months | How long export zip files are kept |
| Document Version Retention | 12 months | How long Document version snapshots are kept |
| Debug/Info Logs, Warn Logs, Error Logs | 7 / 30 / 90 days | Folio Log retention, set separately per level |
All are edited under Advanced Settings on the Admin Panel’s Settings tab. Setting any value to 0 keeps that kind of record forever.
Document versions are the fastest-growing object, at roughly two-thirds of all records Folio creates. A single actively edited Document can accumulate dozens across its retention window, though Folio merges older snapshots to limit this — see How history is consolidated.
Because versions dominate the record count, halving the retention window roughly halves Folio’s total storage footprint. Reducing Document Version Retention from 12 months to 6 is the highest-leverage adjustment available.
Shortening version retention does not delete Documents. It removes older change-history snapshots only. Every Document, along with its current content, is untouched — users lose the ability to compare against or restore from versions older than the window, and nothing else.
Folio Log can also grow in a busy org, which is why Debug/Info Logs defaults to 7 days while Error Logs is kept for 90.
Retention only takes effect when Background Jobs is enabled. The cleanup work runs as scheduled jobs. With Background Jobs disabled, versions, alerts, and logs grow without limit regardless of the retention values. Check this first when auditing storage.
Allocations by edition
Salesforce’s own documentation is the source of truth for these figures. Allocations change, and the tables below can fall out of date. Check data storage allocations and Files storage allocations before relying on them for planning.
Data storage
| Edition | Base | Per user |
|---|---|---|
| Professional | 10 GB | 20 MB |
| Enterprise | 10 GB | 20 MB |
| Performance | 10 GB | 120 MB |
| Unlimited | 10 GB | 120 MB |
| Developer | 5 MB | — |
File storage
| Edition | Base | Per user |
|---|---|---|
| Professional | 10 GB | 612 MB |
| Enterprise | 10 GB | 2 GB |
| Performance | 10 GB | 2 GB |
| Unlimited | 10 GB | 2 GB |
| Developer | 20 MB | — |
Performance and Unlimited receive six times the per-user data storage of Enterprise, so the percentages above drop substantially on those editions. Smaller orgs have less headroom on paper but proportionally fewer users and Documents, so the ratio largely holds.
Check your own usage
From Setup, enter Storage Usage in the Quick Find box and select Storage Usage. The page shows your data and file storage allocations, current usage, and a breakdown of record counts and storage consumed by object. Folio’s objects appear there alongside everything else.
Related: Browse the Glossary · Admin Panel Settings · Browse Document Version History · Understand the Folio Data Model