Scaling a video management system from 100 to 10,000 cameras is not a bigger version of the same architecture — it is a different architecture. The five decisions that matter in 2026 are ingestion, storage tiering, edge-vs-cloud compute split, transcoding strategy, and auto-scaling policy. Get those five right and everything else — observability, compliance, cost — follows. Get any one wrong and the system fails on the day you cross 500 concurrent streams.
Horizontal VMS scale in 2026 means: microservices, edge recording, AV1/H.265 mixed-codec support, and 10,000+ cameras per cluster. Milestone XProtect, Genetec Security Center 5.12+, and Eagle Eye Networks are the three references that ship this at price points that don't require a custom RFP.
Key takeaways
- The five engineering decisions: ingestion protocol mix, storage tiering (hot/warm/cold), edge vs. cloud inference split, codec/transcoding path, and auto-scaling trigger policy.
- Monolith → microservices is no longer optional at 1,000+ streams. Independent scaling of ingest, storage, analytics, and user-plane services is the minimum viable architecture.
- Hybrid edge-cloud is the default in 2026 — on-camera inference plus cloud aggregation beats pure cloud on bandwidth cost and pure edge on analytics depth.
- Storage cost doubles every 18 months of retention. Tiered S3-class storage with event-triggered promotion is the only sustainable model at scale.
- Observability before scale. Metrics, traces, and synthetic health probes must be in place before you cross 500 streams — after that, you are debugging blind.
Why this guide is written by Fora Soft
We have shipped video management systems since 2005. One of them — V.A.L.T. — now serves 650+ US institutions (police departments, universities, behavioral health clinics) with 25,000+ daily users and thousands of concurrent camera streams. This guide is the distilled version of what we learned scaling V.A.L.T. and other VMS platforms through the zero-to-1,000 camera and 1,000-to-10,000 camera transitions. The failure modes we describe are ones we have debugged at 3am, not ones we read about.
Use cloud-native when: you have > 50 cameras or multi-site operations. Hybrid edge+cloud beats pure NVR.
Planning a VMS platform?
We design and ship production VMS architectures that scale from 100 to 10,000+ cameras.
Tell us your target scale, compliance region, and camera mix. We will return a reference architecture and a staged delivery plan in one call.
Book a 30-min architecture call →Decision 1 — Ingestion protocol mix
Every camera and stream in your VMS speaks one of four protocols. Supporting all four natively is the baseline; picking the right default for new onboarding is the leverage.
| Protocol | Latency | Best for | Watch-outs |
|---|---|---|---|
| RTSP | ~200–500ms | Legacy IP cameras, LAN deployments | NAT traversal pain, no built-in auth |
| WebRTC | ~80–200ms | Live monitoring, operator dashboards | Complex SFU ops at scale |
| LL-HLS / DASH | ~2–4s | Public viewer fan-out, CDN-backed | Not viable for interactive control |
| SRT / RTMP | ~1–3s | Contribution feeds, remote cameras | Not browser-native (RTMP EOL in Chrome) |
Our 2026 default for a greenfield VMS: WebRTC for operator live view, LL-HLS for public/viewer fan-out, RTSP for legacy camera ingest, SRT for wide-area contribution. Run all four through a single media server (Flussonic, Wowza, or custom Pion-based Go) that handles protocol normalization and re-packages on the way out. Do not try to pick one protocol — camera vendors and viewer apps will force you to support them all anyway.
Decision 2 — Storage tiering
Storage is 40–60 percent of VMS total cost of ownership at scale. The mistake we see most often: recording everything at full bitrate to hot storage "just in case," and hitting the retention cliff six months later when the monthly bill doubles.
Skip closed ecosystems when: ONVIF + RTSP are now non-negotiable. Vendor lock-in is a 2026 procurement red flag.
01
Hot tier — last 7 days
SSD-backed object storage (S3 Standard, GCS Standard) or local NVMe for on-prem. Full bitrate, indexed by event and time. Retrieval latency under 100ms. This is where live review and incident response happen.
02
Warm tier — 8 to 90 days
S3 Infrequent Access or GCS Nearline. Re-encoded to a lower bitrate (typically 30–40 percent of hot tier) unless regulatory retention mandates full fidelity. Retrieval latency seconds, not milliseconds. Event-tagged clips get promoted back to hot on demand.
03
Cold tier — 90+ days
S3 Glacier Instant or Glacier Flexible Retrieval. Compliance-grade retention (HIPAA, GDPR, CJIS) without the hot-tier cost. Retrieval 1–12 hours, billed separately. For most VMS workloads, 90 percent of data lives here after 90 days.
04
Event-triggered promotion
AI anomaly detection, manual bookmarks, and incident reports automatically promote matching time windows back to hot storage. This is what makes tiering compatible with investigative workflows — your operators never wait for cold retrieval on a flagged event.
Indicative cost math: a single 2 Mbps 1080p stream consumes ~22 GB/day. At 1,000 cameras and 90 days hot retention, that is ~1.98 PB. On AWS S3 Standard at $0.023/GB-month that is ~$45k/month in storage alone. Shift the same data to a 7/83-day hot/warm split with 30% warm bitrate, and the bill drops to ~$14k. Over a year, that single decision is worth $370k.
Decision 3 — Edge vs. cloud compute split
Where you run inference — on the camera, on an edge appliance, or in the cloud — is the single biggest driver of bandwidth cost and analytics latency.
| Location | Latency | Bandwidth | Model ceiling |
|---|---|---|---|
| On-camera | <50ms | Lowest (metadata only) | YOLOv8-nano, MobileNet-class |
| Edge appliance (local) | 100–300ms | Low (LAN only) | YOLOv8-medium, ResNet, Whisper |
| Regional cloud | 500ms–2s | High (full stream upload) | Any — VLMs, large diffusion |
The 2026 pattern that wins: edge-first with cloud escalation. On-camera models filter 99 percent of frames (motion, basic object class). Edge appliances run mid-size models on anything flagged. Only full-segment clips with low-confidence flags escalate to a cloud VLM for deep reasoning. This cuts upstream bandwidth by 90–95 percent compared to naive "upload everything" pipelines, while keeping the deepest analytics still reachable.
Watch-out
Do not rely on camera vendors' onboard AI if you need model updates. Most cameras ship with a frozen inference chip and cannot be retrained on your data. For meaningful AI lift, run inference on an edge Jetson / OpenVINO box you control, even if the cameras also have AI. Treat camera-side AI as a free bonus, not the primary analytics layer.
Decision 4 — Codec and transcoding strategy
Transcoding is where VMS systems quietly consume unbounded compute. Two rules keep it sane:
AI analytics priority: object detection first, anomaly flagging second, search-by-attribute third — they reduce ops cost 50%+.
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 specific viewer requests them, and cache for a short window. Pre-generating a full ABR ladder for every camera is a fast path to a six-figure monthly compute bill at scale.
Rule 2 — Offload with hardware encoders
NVIDIA NVENC, Intel Quick Sync, and Apple VideoToolbox each deliver 10–30× throughput over CPU x264 at acceptable quality. On AWS, a single g5.2xlarge handles 30–50 concurrent live transcodes that would require a c5.12xlarge on CPU alone. Budget this as a first-class capex/opex item, not an afterthought.
AV1 is ready — for cold tier first
AV1 hardware encode (NVIDIA Ada, Intel Arc Battlemage, AMD RDNA4) now runs at real-time speeds. AV1 delivers 30–40 percent bitrate savings vs. H.265 at equivalent quality — huge for storage-dominated VMS workloads. The 2026 play: transcode warm-and-cold tier clips to AV1 on ingest rollover. Keep hot tier in H.264/H.265 for decode compatibility with older client devices.
Decision 5 — Auto-scaling trigger policy
VMS workloads are spiky by nature — end-of-shift reviews, incident responses, scheduled archive retrievals. CPU-based auto-scaling is too slow. Two triggers work better:
Trigger A — Stream count per media node
When any media server crosses 80% of its validated stream-per-node capacity (measured during load tests), spin up a new node and route new connections to it. This triggers in tens of seconds instead of minutes.
Trigger B — Queue depth on transcode workers
Instead of monitoring worker CPU (lagging indicator), monitor the backlog of pending transcode jobs. When queue depth exceeds the typical 5-minute processing window, scale workers horizontally. When it drops below a quiet threshold for 15+ minutes, scale down.
Combine these with spot/preemptible instances for stateless transcode workers (they can die mid-job; the queue redrives) and reserved instances for media servers (stateful, expensive to migrate). Typical savings: 40–60 percent on transcode compute vs. all-on-demand.
Not sure which of these applies to you?
We will review your current or planned architecture against these five decisions.
Share your scale targets and constraints. Walk away with a one-page gap analysis and a prioritized fix list. No obligation.
Book a 30-min architecture call →The microservices decomposition that works
Once you are past ~500 concurrent streams, a monolithic VMS becomes a deployment liability — a single bad release blocks live monitoring, storage, and user management simultaneously. The decomposition that we ship most often:
Common failure mode: ignoring storage strategy. Smart retention cuts storage cost 60-80%.
| Service | Responsibility | Scaling axis |
|---|---|---|
| Ingestion | Accepts RTSP/WebRTC/SRT, normalizes to internal format | Stream count |
| Media router (SFU) | Routes live streams to operator clients | Concurrent viewers |
| Storage writer | Chunks, encrypts, writes to object storage | GB/s ingest |
| Transcode worker | Lower-resolution variants, AV1 warm-tier conversion | Queue depth |
| Analytics | Runs AI inference, emits events | Frames/second |
| Metadata / search | Indexes events, clips, bookmarks; serves search queries | Query QPS |
| Identity / RBAC | AuthN, AuthZ, multi-tenant isolation | User session count |
| Notification | Real-time alerts to operator UIs, email, webhook | Events/second |
Each service has its own scaling axis, its own database (or database shard), and its own deploy cadence. The failure domain of a bad transcode-worker release no longer takes down live monitoring. Kubernetes plus a service mesh (Istio, Linkerd) plus event streaming (Kafka or NATS JetStream) is the typical 2026 implementation substrate.
Case study: V.A.L.T. — the five-decision architecture at 650+ institutions
V.A.L.T. is Fora Soft's video management platform used by over 650 US institutions — police departments, universities, medical facilities, and behavioral health clinics — for interview recording, training review, and clinical supervision workflows. It handles 25,000+ daily users and thousands of concurrent camera streams.
How the five decisions shipped in V.A.L.T.:
- Ingestion mix: RTSP + ONVIF for cameras, WebRTC for live operator review, SRT for remote contribution rooms.
- Storage tiering: 7-day hot / 83-day warm / 7-year cold for interview footage under CJIS and HIPAA compliance requirements. Event-triggered promotion wired into the case-management UI.
- Edge/cloud split: Room-level edge boxes handle motion detection and participant tracking; cloud handles transcription, speaker diarization, and cross-case search.
- Transcode: NVENC-accelerated H.264 for live playback, AV1 conversion at warm-tier rollover, reducing storage cost by ~35 percent.
- Auto-scaling: Stream-count triggers for media nodes; queue-depth triggers for transcode workers; mixed reserved + spot fleet.
The platform operates at 99.95% availability with sub-200ms live latency across US regions. Adding a new institution — often with 50–500 cameras — is a same-day provisioning operation, not a deployment project.
Observability before scale — not after
The most painful VMS scaling failures we have debugged all share the same pattern: observability was bolted on after the system hit trouble, not designed in. The four telemetry surfaces that must exist before 500 concurrent streams:
- Per-stream health metrics (frames ingested, bitrate delivered, packet loss, segment publish latency) exposed as Prometheus time series with per-camera labels.
- End-to-end trace IDs that follow a frame from ingest through transcode through storage write — OpenTelemetry with a sampling rate that can go to 100% under investigation.
- Synthetic probes that continuously pull a reference stream from each region and validate playback latency, resolution, and decode integrity. These catch silent failures that no operator has opened yet.
- Storage access patterns — which time ranges, which cameras, which users are hitting hot vs. warm vs. cold. This is what lets you re-tune the tiering policy quarterly as the workload evolves.
Compliance is an architecture constraint, not a checklist
HIPAA, GDPR, CJIS, and sector-specific regimes (FERPA for education, PCI for retail) all affect VMS architecture — not just policies. The recurring requirements: encryption in transit (TLS 1.3) and at rest (AES-256-GCM with customer-managed keys), region-pinned storage (EU data does not leave EU), audit-log immutability (append-only with tamper-evidence), and RBAC that can enforce least-privilege down to camera and time-window granularity.
Two architecture patterns to build in from day one: (1) per-tenant encryption keys stored in a KMS, so a breach of one tenant's data cannot cascade; (2) 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 is logged in. Retrofitting these after the fact is a months-long project; shipping them at v1 is a few engineering days.
Comparison matrix: build, buy, hybrid, or open-source for scalable VMS
A quick 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 row that sounds most ambitious.
| Approach | Best for | Build effort | Time-to-value | Risk |
|---|---|---|---|---|
| Buy off-the-shelf SaaS | Teams < 10 engineers, generic use case | Low (1-2 weeks) | 1-2 weeks | Vendor lock-in, customization limits |
| Hybrid (SaaS + custom layer) | Mid-market, mixed use cases | Medium (1-2 months) | 1-3 months | Integration debt, two systems to maintain |
| Build in-house (modern stack) | Enterprise, unique data or compliance needs | High (3-6 months) | 6-12 months | Engineering velocity, talent retention |
| Open-source self-hosted | Cost-sensitive, technical team | High (2-4 months) | 3-6 months | Operational burden, security patching |
Frequently asked questions
How many concurrent camera streams can a single media server handle?
Depends on codec, resolution, and whether the server is decoding or just relaying. A single Wowza / Flussonic / Janus / Pion node on an AWS c5.4xlarge typically handles 200–500 concurrent 1080p H.264 streams in relay mode, dropping to 50–150 when decoding for AI or transcoding. Validate your own number with a load test before committing — vendor benchmarks are optimistic.
What is the realistic storage cost for a 1,000-camera VMS with 90-day retention?
At 2 Mbps per stream, 1,000 cameras, 90 days: ~2 PB. On AWS S3 Standard throughout that is ~$45k/month. With a 7-day hot / 83-day warm split at 30% warm bitrate, it drops to ~$14k/month. Add cold-tier archival at 1-year retention and the blended cost per camera per month falls below $15 — achievable and predictable.
When should we move from monolith to microservices?
Concrete trigger: when deploy time is over 10 minutes, or when any single bad release has blocked live monitoring more than once. Both usually happen between 300 and 700 concurrent streams. Do not migrate earlier just because it is architecturally "correct" — the operational overhead of a premature microservice split kills small teams.
Do we need Kubernetes for a VMS?
Below 1,000 concurrent streams and a single region: no. Docker Compose + systemd + a load balancer is simpler and cheaper. Above 1,000 streams or multi-region: Kubernetes becomes net-positive — the auto-scaling, rollout, and service-discovery primitives pay for their operational cost. EKS/GKE/AKS over self-hosted control planes, unless you have a strong platform team.
How do we handle multi-tenant isolation in a shared VMS cloud?
Three layers: (1) per-tenant encryption keys in KMS, so object-storage data is cryptographically isolated; (2) row-level security in the metadata database or separate schemas per tenant; (3) RBAC policies enforced at the API gateway, not only in UI. Audit logs must tag every cross-tenant access attempt. Do not rely on application code alone for isolation — a single bug becomes a cross-tenant breach.
Can we avoid cloud and run the whole VMS on-prem?
Yes, and for some regulated workloads (defense, certain healthcare regimes) it is the only option. The five decisions above still apply — you just substitute MinIO/Ceph for S3, on-prem Kubernetes for EKS, and physical NVENC GPUs for g5 instances. Budget 2–3× the engineering effort for initial platform bring-up and ongoing operations; the logical architecture stays the same.
Read next
VMS features
12 Essential Features of Modern VMS Software in 2026
The feature surface that a scalable VMS should expose — once the architecture underneath is right.
Mobile SDKs
Best Android SDKs for Video Surveillance Apps in 2026
Which mobile SDK to plug into your VMS client — with the same cost/latency/compliance lens.
AI analytics
2026 Android Video Surveillance Trends: 5 AI Features
What the analytics layer looks like on top of the architecture described here.
References
- AWS S3 storage class pricing and performance documentation, 2026.
- NVIDIA NVENC/NVDEC support matrix (Ada, Blackwell architectures).
- Alliance for Open Media AV1 codec deployment reference.
- CNCF Cloud Native Storage Landscape, 2026 edition.
- Fora Soft V.A.L.T. production deployment metrics, internal.
To sum up — five decisions, not five features
Scalable VMS design in 2026 is not about picking the best camera vendor or the biggest cloud region. It is about making five architectural decisions early — ingestion, storage tiering, edge/cloud split, transcoding, auto-scaling — and building observability and compliance into the foundation rather than bolting them on later.
The platforms that scale to 10,000+ cameras are not the ones with the most features. They are the ones where the founding team got these five decisions right on day one, and everything else followed.
Building your VMS?
Let us pressure-test your architecture before it hits production.
Fora Soft has shipped VMS platforms from 100-camera pilots to 10,000+ camera production deployments. Book a call — we will either validate your plan or flag the two things most likely to break at scale.
Book a 30-min architecture call →
.avif)
Comments