Video Surveillance Storage Sizing for Government Agencies
Camera counts make for an easy budget line. Retention requirements are what actually determine whether that number holds up under review.
By Uniqcli Team · · 7 min read
Storage Planning
Video surveillance storage sizing for government starts with retention, not camera count
Every agency video surveillance RFP leads with a camera count — 40 cameras for a parking structure, 120 for a school campus, 200 for a courthouse perimeter. Camera count is the easy number: it drives the procurement line for hardware, cabling, and PoE switch ports, and it's what shows up first in a capital budget request. It is also the wrong number to size storage against. Video surveillance storage sizing is driven by three variables that rarely make it into the initial ask: resolution, frame rate, and retention period — the number of days footage must be held before it can be overwritten. State public-records statutes, department policy, or a specific compliance driver (school safety mandates, critical-infrastructure security plans) usually set retention at 30, 45, or 90 days. Get that number wrong at the design stage and either the system runs out of disk mid-quarter or the agency pays for capacity it never needed.
Why camera count alone can't size a storage array
A camera spec sheet tells you resolution and maximum frame rate. It does not tell you how much data that camera will generate over a 30-day retention window, because that number depends on compression codec, scene motion, and bitrate mode — constant or variable. Two identical 4MP cameras pointed at a quiet hallway and a loading dock with constant vehicle traffic can produce meaningfully different file sizes under variable bitrate encoding, even running the same codec and frame rate.
This is why a storage estimate built purely off camera count times a flat number of terabytes tends to be wrong in one direction or the other. Undersizing shows up months later, when the system silently overwrites footage sooner than policy requires — a finding an auditor or records request will surface at the worst time. Oversizing is quieter but shows up on the purchase order: extra disk shelves, extra rack space, extra power and cooling draw that never gets used.
The fix is a simple per-camera formula applied before the RFP is finalized, not after the array arrives undersized.
The core storage formula: bitrate, retention, and RAID overhead
The starting formula is consistent across manufacturers: daily data per camera, in gigabytes, equals the average bitrate in megabits per second multiplied by roughly 10.8 — the conversion factor for a full 24-hour recording day at that bitrate. Multiply that daily figure by the number of cameras, then by the retention period in days, and the result is raw storage in gigabytes before any redundancy overhead.
Codec choice moves the bitrate more than almost any other variable. H.265 (HEVC) typically cuts bitrate 40-50% versus H.264 at the same resolution and frame rate for equivalent visual quality, because it compresses more efficiently — the tradeoff is higher decoder compute at the viewing station, which is a real but usually minor cost. Frame rate matters less than most buyers assume for detection use cases: 12-15 fps is standard for general area coverage, reserving 25-30 fps for lanes where motion detail — license plates, fast-moving vehicles — is the actual requirement.
Raw storage is not usable storage. RAID 5 or RAID 6 arrays, standard for surveillance-grade NVRs, carry 20-35% overhead depending on drive count and parity configuration. Add a 10-15% working margin for days when network activity runs heavier than average, and the realistic rule of thumb is to budget 35-45% above the raw math before pricing the array.
Three retention scenarios, worked out
Applying the formula to three common government scenarios shows how fast the numbers move once retention and camera count both scale up.
A municipal parking structure with 40 fixed 1080p cameras at 15 fps, H.265, and a 30-day retention policy: roughly 2 Mbps average bitrate per camera works out to about 21.6 GB per camera per day, or 864 GB per day across the deployment. Over 30 days that's approximately 26 TB of raw video. With RAID overhead and working margin, the array should be specified around 35-38 TB usable.
A school campus with 120 cameras at 4MP resolution, 20 fps, and a 45-day retention requirement common to state K-12 safety statutes: bitrate climbs to roughly 4 Mbps per camera, or about 43 GB per camera per day — 5.2 TB per day across the campus. At 45 days that's north of 230 TB raw, which typically means a purpose-built NVR cluster rather than a single appliance.
A critical-infrastructure perimeter with 24 cameras at 4K, continuous recording, and a 90-day retention window: even at a modest 10 Mbps average bitrate, that's roughly 108 GB per camera per day, or 2.6 TB per day site-wide — about 233 TB raw over the full retention period. High-resolution, long-retention deployments like this are exactly where storage cost overtakes camera cost in the total procurement.
Where agencies actually blow the budget
The single most common overrun is retention creep after award: a policy team extends the requirement from 30 to 60 or 90 days after the array is already sized, and there's no headroom built in. Specifying the array with the actual policy retention plus one review cycle of margin avoids a mid-contract change order.
The second is resolution upgrades outpacing the storage design. A camera refresh that swaps 2MP for 4MP or 4K units mid-lifecycle roughly doubles or triples per-camera storage draw, but the recording infrastructure underneath frequently isn't re-evaluated until the array starts alerting on capacity. Sizing storage against the resolution the agency is likely to standardize on next, not just what's installed today, avoids that gap.
The third is treating every camera the same. Not every camera needs identical frame rate, resolution, or retention — a lobby camera and a perimeter fence line rarely carry equal evidentiary weight. Tiering camera specs and retention by zone, with high-priority access points at higher fps and resolution and general coverage at lower, can cut total storage 20-30% without reducing coverage where it matters.
Storage sizing checklist before the RFP goes out
Work through these before the camera spec locks the storage design:
- Confirm the retention period required by policy or statute for each camera zone, not a single blanket number
- Document target resolution and frame rate per camera, not per project
- Confirm codec — H.265 preferred where camera and NVR both support it
- Calculate raw storage per camera per day using bitrate x 10.8
- Multiply by camera count and retention days for total raw storage
- Add RAID/parity overhead (20-35%) based on the array's drive configuration
- Add 10-15% working margin for above-average network days
- Plan for one retention-policy review cycle of headroom, not just current policy
- Separate high-priority zones (entry points, evidentiary areas) from general coverage for tiered specs
- Confirm NVR/VMS licensing scales with camera count and doesn't cap storage expansion
Frequently asked
How much storage does a government surveillance system need per camera?
It depends on resolution, frame rate, codec, and retention period, not a flat number. As a rough baseline, a 1080p camera at 15 fps with H.265 compression and 30-day retention needs roughly 650 GB of raw storage; a 4K camera at the same settings needs 3-4x that. Always calculate per camera, then scale by the actual deployment count and retention requirement.
How many days should government video surveillance be retained?
Retention is set by agency policy, state public-records law, or a specific compliance driver — there's no universal number. 30 days is common baseline practice; K-12 and critical-infrastructure sites frequently require 45-90 days. Confirm the requirement with the records-management or legal team before sizing storage, since it's the single largest driver of total capacity.
Does H.265 really cut storage needs in half compared to H.264?
Roughly, yes — H.265 (HEVC) typically reduces bitrate 40-50% versus H.264 at equivalent resolution and visual quality, which translates almost directly into lower storage consumption. The tradeoff is higher processing demand on the viewing side, which matters for older workstations but is a minor cost against the storage savings on any deployment running more than a handful of cameras.
Should every camera in a system use the same frame rate and resolution?
No. Tiering specs by zone — higher resolution and frame rate at access points, license-plate lanes, or evidentiary areas, and lower settings for general area coverage — is standard practice and can reduce total storage 20-30% versus a flat spec applied system-wide, without reducing coverage where detail actually matters.
Related resources
Go deeper
Access control & video integration
Camera selection, NVR/VMS integration, and access-control tie-ins sourced and staged as one project.
Learn morePublic safety sector guidance
Procurement patterns and equipment considerations specific to public safety and first-responder agencies.
Learn moreBrowse the surveillance catalog
Cameras, NVRs, storage arrays, and switching gear available for quote across resolution and retention tiers.
Learn moreSize the array before the RFP locks the spec
Send camera count, resolution, frame rate, and retention requirement — we'll work the storage math and quote hardware sized to the actual policy, not a rounded-up guess.