Camera throughput in a surveillance server refers to the total volume of video data the server can continuously receive, process, and write to storage without dropping frames or degrading performance. It is typically measured in megabits per second (Mbps) or gigabits per second (Gbps) and represents the practical ceiling for how many cameras a server can handle at a given quality level. The sections below unpack how throughput is measured, what limits it, and how to calculate what your deployment actually needs.
How is camera throughput measured in a surveillance server?
Camera throughput in a surveillance server is measured as the total sustained data rate the server can receive, process, and write to disk simultaneously, expressed in megabits per second (Mbps) or megabytes per second (MB/s). The key word is sustained: peak burst performance is largely irrelevant in surveillance, where streams flow continuously, 24 hours a day, every day of the year.
To arrive at a meaningful throughput figure, engineers measure the combined incoming bitrate from all connected IP cameras and compare it against what the server’s storage subsystem can write without buffer overflow or frame loss. A server rated at 1,000 Mbps of sustained write throughput can theoretically handle that total bitrate across however many cameras contribute to it, whether that is 20 cameras at 50 Mbps each or 100 cameras at 10 Mbps each.
It is important to distinguish between network throughput (the rate at which data arrives at the server’s network interface) and disk write throughput (the rate at which the storage array can commit that data permanently). Both must be measured and matched. A server with a 10 Gbps network interface but a storage array that can only sustain 500 MB/s of sequential writes will bottleneck at the storage layer long before the network becomes a constraint.
What factors limit how many cameras a server can handle?
The number of cameras a surveillance server can handle is limited by several interdependent factors: storage write throughput, CPU processing headroom, network interface capacity, RAM availability, and the efficiency of the Video Management System (VMS) software running on top. No single component tells the whole story: the weakest link in the chain defines the real-world ceiling.
Storage write throughput is usually the first constraint in high-camera-count deployments. Generic enterprise IT servers use storage arrays designed for random read/write workloads such as databases. HD surveillance generates continuous sequential write workloads, which behave very differently. Arrays not optimised for this pattern suffer from fragmentation, write amplification, and degraded sustained performance over time, reducing effective camera capacity well below the theoretical maximum.
CPU load matters most when the server is also running analytics, motion detection, or transcoding tasks alongside recording. Each of these adds processing overhead that competes with the core recording function. Network interface saturation becomes a factor in very large deployments: a single 1 Gbps NIC has a hard ceiling of roughly 1,000 Mbps of incoming camera data, making dual or multi-port configurations necessary at scale. RAM affects how many concurrent camera streams the VMS can buffer and manage without performance degradation.
How does video resolution affect server throughput?
Video resolution directly determines the bitrate of each camera stream, which in turn defines how much of the server’s total throughput budget each camera consumes. Higher resolution means more pixel data per frame, which means a larger bitrate, and therefore fewer cameras before the server’s throughput ceiling is reached.
As a practical illustration: a standard 2MP (1080p) camera running H.264 at typical surveillance quality might generate 4 to 8 Mbps. A 4K (8MP) camera under similar conditions can easily produce 16 to 25 Mbps or more. On a server with 500 Mbps of sustained write throughput, the difference between those two resolutions could mean the difference between supporting 60 cameras and supporting fewer than 20.
Compression codec choice compounds this effect. H.265 (HEVC) and H.265+ encoding can reduce bitrate by roughly 50% compared to H.264 at equivalent visual quality, effectively doubling the number of cameras a given throughput budget can support. However, H.265 decoding is more CPU-intensive, so the gain in storage throughput must be weighed against the increased processing demand on the server. Frame rate is equally important: recording at 25fps versus 5fps produces five times the data volume per camera, dramatically accelerating throughput consumption.
What is the difference between throughput and storage capacity in a surveillance server?
Throughput and storage capacity are two separate and equally critical specifications in a surveillance server. Throughput determines how many cameras the server can record simultaneously without dropping frames. Storage capacity determines how many days of recorded footage the server can retain before older footage is overwritten. A server can have enormous storage capacity but insufficient throughput, or excellent throughput but inadequate retention, and either shortfall makes it unfit for purpose.
Think of throughput as the width of a pipe and storage capacity as the size of the tank at the end. A wide pipe that feeds into a small tank fills and overflows quickly. A large tank fed by a narrow pipe cannot keep up with high-camera-count deployments. Both dimensions must be sized correctly and in proportion to each other for the system to function reliably.
In practice, many surveillance deployments discover this mismatch too late. A specifier might correctly calculate the total terabytes needed for 30 days of retention across 64 cameras, then install a server with adequate raw disk space, only to find that the storage controller or RAID configuration cannot sustain the write throughput those 64 cameras demand simultaneously. The result is frame drops, recording gaps, or system instability that no amount of additional disk space will fix.
How do you calculate the throughput needed for a surveillance deployment?
To calculate the throughput needed for a surveillance deployment, multiply the average bitrate of each camera by the total number of cameras, then add a headroom margin of at least 20 to 30 percent to account for bitrate spikes, motion events, and analytics overhead. The result is the minimum sustained write throughput your server must reliably deliver.
A straightforward calculation for a 64-camera deployment using 4MP cameras at H.265 encoding, averaging 8 Mbps per stream, looks like this:
- 64 cameras × 8 Mbps = 512 Mbps total incoming bitrate
- Add 25% headroom: 512 × 1.25 = 640 Mbps required sustained throughput
- Convert to MB/s for storage sizing: 640 Mbps ÷ 8 = 80 MB/s minimum sustained disk write speed
This calculation must account for the worst-case scenario, not the average. In environments with significant motion (transport hubs, busy retail spaces, or stadiums), variable bitrate encoding means camera streams spike well above their average during peak activity. Specifying to the average and ignoring peaks is a common cause of frame loss in live deployments.
Analytics workloads add a further layer of complexity. If the server is running video analytics, object detection, or licence plate recognition alongside recording, CPU and memory demand increases substantially, and the throughput headroom margin should be widened accordingly. Tools such as Secure Logiq’s proprietary Logiqal Benchmark utility allow system designers to simulate an entire camera network (including specific resolutions, codecs, frame rates, and analytics loads) to validate server throughput before any hardware is physically deployed.
Why does VMS software affect camera throughput on the same hardware?
VMS software significantly affects camera throughput on identical hardware because different platforms have fundamentally different architectures for how they receive, decode, buffer, and write video streams. The efficiency of a VMS’s recording engine, its memory management, and how it interacts with the underlying storage layer all determine how much of the server’s raw hardware throughput is actually usable for recording cameras.
Some VMS platforms handle each camera stream as an individual process or thread, which creates high CPU overhead at scale. Others use more efficient pooled architectures that reduce per-camera processing cost. The difference can be substantial: the same physical server might support 64 cameras reliably under one VMS and struggle with 40 under another, purely because of how each platform manages resources internally.
Driver compatibility and codec handling also vary between platforms. A VMS that requires server-side transcoding for certain camera models (converting streams from one codec to another for display or analytics purposes) consumes significant CPU cycles that would otherwise be available for recording additional streams. This is one reason why hardware certified and validated for specific VMS platforms consistently outperforms generic servers in real-world deployments: the hardware and software have been tested together to ensure the recording engine operates at peak efficiency without unexpected bottlenecks.
Platforms such as Milestone XProtect, Genetec Security Center, and Avigilon Unity each have distinct performance characteristics, and the practical camera throughput achievable on a given server will differ between them even when every other variable is held constant.
How Secure Logiq helps you maximise camera throughput
Secure Logiq designs and manufactures HD surveillance servers built specifically to eliminate the throughput bottlenecks that generic IT hardware introduces into large-scale CCTV deployments. Every server addresses the core constraints covered in this article:
- Purpose-built storage arrays: Hardware RAID configurations using 24/7 surveillance-optimised drives deliver consistent sustained write throughput for continuous sequential video workloads, with hot-swappable spares to maintain performance during a drive failure
- OS isolation: Dual enterprise SSDs in RAID 1 keep the operating system entirely separate from recording storage, protecting throughput stability from software events
- VMS-certified performance: All servers are tested and certified across leading platforms including Milestone XProtect, Genetec Security Center, and Avigilon Unity, ensuring the hardware and software work together at maximum efficiency
- Pre-deployment validation: The proprietary Logiqal Benchmark tool simulates your exact camera mix, resolutions, frame rates, and analytics loads before hardware is ordered, so throughput is guaranteed rather than estimated
- Engineered headroom: Entry-level units deliver double the sustained throughput of comparable off-the-shelf alternatives, giving deployments the margin they need for bitrate spikes and future camera expansion
If you are specifying a surveillance infrastructure and want throughput validated before you commit to hardware, speak to the Secure Logiq design team for a free pre-sales architecture review tailored to your camera count, resolution mix, and VMS platform.
Related Articles
- What is storage density in a surveillance server?
- Can a standard IT server handle HD surveillance workloads?
- What factors affect surveillance server storage requirements in 2026?
- What network bandwidth does an HD surveillance server need?
- What is the difference between M series and H series surveillance servers?