Scalable Video Management Systems for 10,000 Cameras (2026)

Scaling a video management system from 100 to 10,000 cameras is not a bigger version of the same architecture. It is a different one. Scalable video management systems stand or fall on five engineering decisions: ingestion, storage tiering, the edge-versus-cloud compute split, transcoding, and auto-scaling policy. Get those five right and observability, compliance, and cost fall into place. Get any one wrong and the system buckles the day you cross 500 concurrent streams. This playbook is how we build them.

Updated October 2026: storage math re-checked against 2026 S3 volume tiers, ONVIF Profile S phase-out, EU AI Act biometric deadline moved to December 2027, new multi-site scaling section.

Why Fora Soft wrote this scalable VMS playbook

We have built video and surveillance software since 2005: 250+ projects, 50+ in-house specialists, and one product that lives exactly at the scale this article is about. V.A.L.T. is our video management platform for regulated recording. It serves 770+ US organizations (police departments, universities, and behavioral-health clinics) with 50,000+ users and thousands of concurrent camera streams under HIPAA and CJIS retention rules.

This is the distilled version of what that taught us: the failure modes below are ones we have debugged at 3am, not ones we read about. If you are choosing whether to build, buy, or extend a video surveillance and VMS platform, the five decisions here are where the money and the risk actually sit. Everything downstream is a consequence of getting them right.

What makes a video management system scalable?

A video management system is scalable when each part of it grows on its own axis without forcing the others to grow with it. Concretely: adding 1,000 cameras raises ingest and storage load but leaves the search API untouched; a spike in operators watching live raises the media-router load but not the transcode queue. A scalable VMS separates those axes so you provision the one under pressure and pay for nothing else. A non-scalable VMS couples them, so one busy subsystem drags the whole platform, and the monthly bill, up with it. If you are still deciding what the platform has to do before deciding how it scales, start with what video management software is and what it costs.

The tools behind scalable video, in one line: a media server that normalizes every protocol (Wowza, Flussonic, Janus, LiveKit or a Pion-based service), S3-compatible object storage with storage-class tiers, an event bus (Kafka or NATS JetStream), GPU encoders (NVENC on NVIDIA L4-class cards), edge inference boxes such as NVIDIA Jetson, and Kubernetes once you pass about 1,000 streams. None of them scales a VMS on its own; the architecture that keeps their scaling axes apart does. If your load is live viewers and calls rather than cameras, the scalable video streaming and conferencing playbook covers SFU sizing, CDN and egress instead.

That definition is the test we apply to every design review. If a proposed change makes two subsystems scale together that used to scale apart, it is a regression, however clean the code looks. The five decisions below are the load-bearing ones. Figure 1 shows where each sits on the path a frame travels from a camera to an operator’s screen.

Figure 1. Each of the five decisions governs a different stage of the camera-to-client path.

Decision 1 — Ingestion protocol mix

Every camera and stream speaks one of four protocols. Supporting all four is the baseline; picking the right default for new onboarding is where the payoff is. You will not get to standardize on one. Camera vendors and viewer apps force you to carry them all.

Our 2026 default for a greenfield build: WebRTC for operator live view, LL-HLS for public fan-out, RTSP for legacy camera ingest, SRT for wide-area contribution. Run all four through one media server that normalizes on the way in and re-packages on the way out — Flussonic, Wowza, or a custom Pion-based Go service. The normalization layer is the whole point: downstream services should never know or care which protocol a frame arrived on.

One 2026 change for camera onboarding: ONVIF announced in October 2025 that it is phasing out Profile S, and its June 2026 conformance test tool is the last release that lets manufacturers claim Profile S (the tool stays valid for nine months), per the ONVIF announcement. Make Profile T (H.264/H.265 streaming, HTTPS, stronger authentication) the baseline for new cameras, add Profile M for analytics metadata and Profile G for edge recording, and keep Profile S devices on a legacy ingest path. Our ONVIF profile decision guide (S, G, T, M) shows which profile carries what.

Decision 2 — Storage tiering

Storage is 40–60% of total cost of ownership at scale, so this is the decision that quietly decides your margin. The mistake we see most: record everything at full bitrate to hot storage “just in case,” then hit the retention cliff six months in when the monthly bill doubles. Tiering is the fix, and it has four moving parts.

Hot tier — last 7 days

SSD-backed object storage (S3 Standard, GCS Standard) or local NVMe on-prem. Full bitrate, indexed by event and time, retrieval under 100 ms. This is where live review and incident response happen, and it is the only tier that needs to be fast.

Warm tier — 8 to 90 days

S3 Standard-Infrequent Access or GCS Nearline, re-encoded to roughly 35% of the hot bitrate unless a regulation mandates full fidelity. Retrieval in seconds. Event-tagged clips get promoted back to hot on demand, so an investigator never waits.

Cold tier — 90+ days

S3 Glacier Instant Retrieval for compliance-grade retention (HIPAA, GDPR, CJIS) without the hot-tier price. Data stays milliseconds-available but carries a per-GB retrieval fee on read, so it fits archives you rarely touch. For most workloads, 90% of the data lives here after 90 days and is never read again.

Event-triggered promotion

Anomaly detection, manual bookmarks, and case reports automatically promote the matching time windows back to hot storage. This is what makes tiering compatible with investigations: the cost model is cold, but the workflow feels hot on anything flagged.

Decision 3 — Edge vs. cloud compute split

Where inference runs (on the camera, on an edge appliance, or in the cloud) is the single biggest driver of bandwidth cost and analytics latency. It matters more than which model you pick.

Figure 2. Latency and upstream bandwidth by inference tier. Pushing work to the edge collapses both.

The pattern that wins in 2026 is edge-first with cloud escalation. On-camera models filter 99% of frames on motion and basic object class. Edge appliances run mid-size models on anything flagged. Only low-confidence clips escalate to a cloud anomaly-detection model for deep reasoning. That cuts upstream bandwidth 90–95% against a naive “upload everything” pipeline while keeping the deepest analytics reachable. Our computer vision for video surveillance team builds exactly this split, with detection and tracking on NVIDIA Jetson at the edge and escalation to the cloud.

Decision 4 — Codec and transcoding strategy

Transcoding is where a VMS quietly consumes unbounded compute. Two rules keep it sane, and one codec call keeps storage cheap.

Rule 1 — Record once, transcode on demand

Store the camera’s native codec (usually H.264 or H.265) at source bitrate. Generate lower-resolution variants only when a viewer asks, and cache them briefly. Pre-building a full adaptive-bitrate ladder for every camera is the fast path to a six-figure monthly compute bill.

Rule 2 — Offload to hardware encoders

NVIDIA NVENC, Intel Quick Sync, and Apple VideoToolbox each deliver 10–30× the throughput of CPU x264 at usable quality. On AWS, a G6 instance carries an NVIDIA L4 with two NVENC encoders, four decoders and AV1 hardware encode (AWS G6 specs); one card typically sustains a few dozen concurrent 1080p live transcodes that would otherwise take a large CPU fleet. The older G5 (A10G) still works for H.264/H.265 but cannot encode AV1. Budget it as a first-class line item, not an afterthought.

AV1 is ready — for the cold tier first

Hardware AV1 encode (NVIDIA Ada and Blackwell, Intel Arc, AMD RDNA3 and RDNA4) now runs at real time. Per the Alliance for Open Media, AV1 gives roughly 30% bitrate savings over H.265 at equal quality — large money on a storage-dominated workload. The play: transcode warm- and cold-tier clips to AV1 on ingest rollover, and keep the hot tier in H.264/H.265 for decode compatibility with older client devices.

Decision 5 — Auto-scaling trigger policy

VMS load is spiky by nature: shift-end reviews, incident responses, scheduled archive pulls. CPU-based auto-scaling reacts too late — by the time CPU climbs, streams are already dropping. Two signals work better.

Figure 3. Provisioning on stream count fires tens of seconds before a CPU trigger would, ahead of the shift-end spike.

Trigger A — stream count per media node. When any media server crosses 80% of its load-tested stream-per-node capacity, provision a node and route new connections to it. This fires in tens of seconds, not minutes.

Trigger B — queue depth on transcode workers. Watch the backlog of pending jobs, not worker CPU. When queue depth exceeds a five-minute processing window, add workers; when it stays quiet for 15 minutes, scale down.

Pair those with spot instances for stateless transcode workers (they can die mid-job; the queue redrives) and reserved instances for stateful media servers. Typical saving: 40–60% on transcode compute against all-on-demand.

The microservices decomposition that scales

Past ~500 concurrent streams, a monolithic VMS becomes a deployment liability: one bad release blocks live monitoring, storage, and user management at once. The decomposition we ship most often gives every service its own scaling axis, its own datastore, and its own deploy cadence. An event bus (Kafka, which since version 4.0 in March 2025 runs without ZooKeeper, or NATS JetStream) decouples them so a slow transcode worker never stalls the live path.

Figure 4. A reference architecture for 10,000+ cameras. Each service scales on the axis noted beneath it.

The failure domain of a bad transcode-worker release no longer reaches live monitoring. Kubernetes plus a service mesh (Istio or Linkerd) plus event streaming is the usual 2026 substrate — but only past the threshold where it earns its operational cost, which the FAQ pins down.

How do you scale a VMS across many sites?

Federate, do not centralize everything. Past one site, each site keeps its own recording tier and a central management layer sits above them, so a WAN outage stops remote viewing but never stops recording. Four patterns carry most large deployments:

• Federation. A parent management server over child sites that keep local recording, local auth cache and local operators. Search, alarms and audit roll up to the parent; footage stays where it was recorded unless someone pulls it. We break down the trade-offs in how VMS federation runs many sites as one.
• Live view at tile resolution. A 16-tile video wall should pull each camera’s substream, not the 4K main stream, and switch to the main stream only when an operator goes full screen. Recording stays at full resolution; only the live WAN traffic shrinks.
• Edge buffering. Cameras or site recorders keep writing locally while the uplink is down (ONVIF Profile G covers edge recording and replay) and backfill central storage when it returns, so a fibre cut does not leave a gap in evidence.
• N+1 recorders. Every site runs one spare recording node; when a node dies, its cameras re-home to the spare in seconds and the cloud writers redrive from the queue, so the KPI of zero dropped recordings holds.

Plan for growth that is not cameras, too: new buildings, access control, alarm panels and directory integration usually arrive within the same three-year window, and each one lands on the management layer rather than the recorders.

Storage cost math: what 1,000 cameras really cost

Numbers make this decision concrete, so here is the arithmetic in full, at AWS S3 US list prices for 2026 (S3 pricing). One 2 Mbps 1080p stream writes 2 Mbps × 86,400 s = 21.6 GB per day. At 1,000 cameras and 90-day retention that is 1,000 × 21.6 × 90 ≈ 1.94 PB.

Flat on S3 Standard at the $0.023/GB-month headline rate: 1,944,000 GB × $0.023 ≈ $44.7k per month. S3 applies volume tiers automatically ($0.022/GB past 50 TB, $0.021/GB past 500 TB, US East, 2026), which trims the real flat bill to about $41.4k.

Tiered 7-day hot / 83-day warm. Hot: 1,000 × 21.6 × 7 = 151,200 GB × $0.023 ≈ $3.5k. Warm, re-encoded to 35% bitrate on S3-IA ($0.0125/GB): 1,000 × 21.6 × 0.35 × 83 = 627,480 GB × $0.0125 ≈ $7.8k. Total ≈ $11.3k per month (about $11.2k after volume tiers) — roughly $30k a month, or about $360k a year, saved by one tiering decision. Figure 5 charts the two side by side.

Figure 5. Flat storage versus a hot/warm tiering split, 1,000 cameras at 90-day retention (AWS S3 headline rates, US, 2026).

One AWS detail shapes the design: lifecycle rules cannot move an object from S3 Standard to Standard-IA before it is 30 days old, Standard-IA bills a 30-day minimum and Glacier Instant Retrieval a 90-day minimum. So the 7-day handover is not a lifecycle transition: the re-encoded warm copy is written as a new object straight into the Standard-IA class and the hot original is deleted. Reads cost extra too, at $0.01/GB from Standard-IA and $0.03/GB from Glacier Instant Retrieval (S3 pricing), so put investigations on event-triggered promotion, not on bulk scans of the archive.

For the oldest footage, Glacier Instant at $0.004/GB is about a third the price of Standard-IA, so extending retention to a full year with a cold tier adds roughly $8 per camera per month. The blended cost then lands near $20 per camera per month at one-year retention, versus about $45 at only 90 days in a flat hot bucket, and roughly $165 per camera per month if a full year sat on S3 Standard. We keep our development estimates conservative because we build with Agent Engineering, so the number you get is one we can actually hit, not a hopeful range.

Observability before scale, not after

The most painful scaling failures we have debugged share one cause: observability was bolted on after trouble, not designed in. Four telemetry surfaces have to exist before you cross 500 concurrent streams, or you are debugging blind past that point.

• Per-stream health metrics — frames ingested, bitrate delivered, packet loss, segment-publish latency — as Prometheus time series with a label per camera.
• End-to-end trace IDs that follow a frame from ingest through transcode to storage write, sampled with OpenTelemetry and pushed to 100% under investigation.
• Synthetic probes that pull a reference stream from each region and check playback latency, resolution, and decode integrity — these catch silent failures before any operator files a ticket.
• Storage access patterns — which cameras, time ranges, and users hit hot versus warm versus cold — so you can re-tune the tiering policy every quarter as the workload shifts.

Compliance is an architecture constraint, not a checklist

HIPAA, GDPR, CJIS, and sector rules (FERPA for education, PCI for retail) shape the architecture, not just the policy binder. The recurring requirements are encryption in transit (TLS 1.3) and at rest (AES-256-GCM with customer-managed keys), region-pinned storage so EU data never leaves the EU, append-only tamper-evident audit logs, and role-based access that reaches down to a single camera and time window.

Analytics adds a 2026 layer for EU sites. Under the EU AI Act, real-time remote biometric identification in publicly accessible spaces for law enforcement has been prohibited since 2 February 2025, outside narrow exceptions. The Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026) moved the obligations for Annex III high-risk systems, which include biometric identification, from 2 August 2026 to 2 December 2027 (White & Case summary). If face recognition is on your EU roadmap, design logging, human oversight and data governance in now: the deadline moved, the requirements did not.

Two patterns belong in v1 because retrofitting them is a months-long project: per-tenant encryption keys in a KMS, so a breach of one tenant’s data cannot cascade; and region-aware routing in the ingestion layer, so a camera on an EU network never has its frames routed through US infrastructure regardless of where the operator logged in. Shipping both at v1 costs a few engineering days. We learned that order the hard way, on V.A.L.T., where CJIS and HIPAA rules touch every recording.

Case study: V.A.L.T. at 770+ organizations

V.A.L.T. is our video management platform for interview recording, training review, and clinical supervision. It runs at 770+ US organizations — police departments, universities, medical and behavioral-health facilities — with 50,000+ users and thousands of concurrent camera streams, and we have been its sole development team for over ten years.

How the five decisions shipped in it:

• Ingestion mix: RTSP and ONVIF for cameras, WebRTC for live operator review, SRT for remote contribution rooms.
• Storage tiering: a 7-day hot / 83-day warm / multi-year cold split for footage under CJIS and HIPAA, with event-triggered promotion wired straight into the case-management UI.
• Edge/cloud split: room-level edge boxes handle motion detection and participant tracking; the cloud handles transcription, speaker diarization, and cross-case search.
• Transcode: NVENC-accelerated H.264 for live playback, AV1 conversion at warm-tier rollover, cutting storage cost by about 35%.
• Auto-scaling: stream-count triggers for media nodes, queue-depth triggers for transcode workers, on a mixed reserved-plus-spot fleet.

The platform holds sub-200 ms live latency across US regions, and onboarding a new organization, often 50 to 500 cameras, is a same-day provisioning task, not a deployment project. That is the payoff of getting the five decisions right once: growth becomes configuration, not re-architecture. Want a similar assessment of your stack? An independent architecture review checks your system against these five decisions, or book a 30-min scoping call to start with the one that hurts most.

Build, buy, hybrid, or open-source: the comparison

A decision grid for the four typical 2026 paths. Pick the row that matches your team size, regulatory surface, and time-to-value target — not the one that sounds most ambitious.

If you are comparing named platforms rather than approaches, here is how the major VMS vendors line up against the five scaling decisions. We build the custom column; the others we have integrated against in the field.

A decision framework in five questions

Five questions settle most build-versus-buy VMS debates faster than a month of meetings.

1. How many cameras in 24 months? Under 50 on one site, buy an NVR. Past a few hundred or multi-site, the five decisions here start deciding your cost structure.

2. What compliance regime? HIPAA, CJIS, or GDPR with customer-managed keys pushes you toward custom or hybrid; a generic SaaS rarely exposes the controls auditors ask for.

3. Is analytics your product or a feature? If search-by-event or a specific detector is the reason customers pay, own it. If you just need boxes-around-people, a packaged platform is fine.

4. What is your egress bill? If cloud egress already hurts, the edge/cloud split is your highest-ROI decision and argues for infrastructure you control.

5. Do you have a platform team? Kubernetes, a service mesh, and an event bus need care and feeding. No platform team means buy or hybrid, or bring in a dedicated video engineering team that builds and runs the platform with you — that is the team we are.

Five pitfalls that break VMS at scale

1. Recording everything hot. The single most expensive default. Without a tiering policy, storage cost compounds until the finance team notices — usually right after a retention-policy change doubles it.

2. Splitting into microservices too early. Below ~500 streams, a premature microservice split adds operational overhead that a small team pays for daily and rarely recovers. Do it when deploy time crosses ten minutes, not before.

3. Trusting camera-vendor AI as the analytics layer. Frozen inference chips cannot be retrained on your data. Build on an edge box you control and treat on-camera AI as a bonus.

4. Auto-scaling on CPU. CPU is a lagging signal. By the time it climbs, the media node is already dropping streams. Scale on stream count and queue depth instead.

5. Bolting on compliance late. Per-tenant keys and region-aware routing are a few days at v1 and a multi-month migration afterward. Every regulated project we rescue skipped them at the start.

The KPIs that prove the architecture holds

Quality KPIs. Live glass-to-glass latency (target sub-200 ms on WebRTC), decode success rate per region from synthetic probes (target > 99.9%), and analytics false-alarm rate (tune until operators stop ignoring alerts).

Business KPIs. Blended storage cost per camera per month (about $11 at 90-day retention with tiering, ~$20 at one-year), transcode compute cost per 1,000 stream-hours, and time-to-onboard a new site (target same-day, not project-length).

Reliability KPIs. Availability on the live path (target 99.95%+), mean time to detect a silent stream failure (synthetic probes, not tickets), and recovery time after a single node loss (target zero dropped recordings via queue redrive).

When not to build a custom scalable VMS

Honesty sells better than a pitch, so here is when the answer is not us. If you run under 50 cameras on one site with generic monitoring needs, a packaged NVR or a cloud VMS subscription beats any custom build on both cost and time. If your requirements are wholly covered by an off-the-shelf platform and you have no compliance or analytics angle of your own, buying is the right call — do not pay engineers to rebuild a solved problem.

Custom scalable video management systems earn their cost when compliance, multi-tenancy, a specific analytics workflow, or an egress bill you cannot escape makes the packaged option the expensive one. If none of those is true today, bookmark this page and revisit it when one becomes true. It usually does.

Frequently asked questions

What to read next

Scalable VMS: five decisions, not five features

Scalable video management systems are not won by the best camera vendor or the biggest cloud region. They are won by making five architectural decisions early (ingestion, storage tiering, the edge/cloud split, transcoding, and auto-scaling) and building observability and compliance into the foundation instead of bolting them on.

The platforms that reach 10,000+ cameras are not the ones with the most features. They are the ones whose founding team got these five right on day one, so everything after was configuration. If you are at the point where camera counts are turning into an architecture problem, that is exactly the conversation we like having.

The handbook · 7 volumes

Fora Soft Video Engineering Handbook

Ingest mix, storage tiers and transcoding strategy decide whether a VMS holds at 10,000 cameras, and each of those choices sits on deeper video engineering. We wrote a seven-volume handbook on the whole video stack, from encoding and delivery to sound and AI. Start with Video Encoding for codecs and bitrate, then the transport volume for RTMP, SRT and ingest, and AI for Video for detection and tracking. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · 9,000+ pages · Kindle & paperback