Hardware & Sizing

Sizing an LPR corridor network, from 100 cameras to 10,000.

The compute requirement is modest and predictable. The image storage is not. Move the slider to your camera count and the specification follows — then read the reference architecture we would actually build at national scale.

100 LPR cameras

Retention

Plate reads / day500 K5,000 per camera

Average requests / s6Sustained, over 24 hours

Peak requests / s173× the daily average

vCPU required8Application tier, aggregate

Memory32 GBAggregate across the tier

Database100 GBDedicated NVMe

Image data4.4 TBAt 90 days — stored data, not disk

Image tier provisioned≈ 6 TB1.35× the data — parity, snapshots, rebuild

Network250 MbpsNext standard link above 2 Mbps/camera

Application cluster3 × 4 vCPU2 working + 1 spare · 12 vCPU installed

Ingestion design target20 – 30/sAbove peak, for surge and replay

Image growth48.6 GBPer day, before any retention

This is a published tier — compute, database and network match the sizing table row below exactly.

The slider needs JavaScript. The figures shown are for 100 cameras at 90-day retention; the full per-tier table is immediately below.

The sizing sheet

Requirement by deployment tier

Every row assumes the same workload profile per camera. Find your camera count, then read across — or use the slider above for a count that is not listed.

Cameras	Reads / day	Peak req/s	vCPU	RAM	DB disk	Images 30 d	Images 90 d	Network
100	500 K	17	8	32 GB	100 GB	1.5 TB	4.4 TB	250 Mbps
250	1.25 M	43	16	64 GB	250 GB	3.6 TB	10.9 TB	500 Mbps
500	2.5 M	87	24	96 GB	500 GB	7.3 TB	21.9 TB	1 Gbps
1,000	5 M	174	48	192 GB	1 TB	14.6 TB	43.8 TB	2 Gbps
5,000	25 M	868	160	512 GB	4 TB	73 TB	219 TB	10 Gbps
10,000	50 M	1,736	320	896 GB	8 TB	146 TB	438 TB	25 Gbps

How to read it

Four constants hold across every row, which is what lets the slider derive a tier the sheet does not list:

5,000 reads per camera per day. A 750-camera deployment is 3.75 M reads/day.
Peak is 3× the daily average. 50 M reads/day is 579/s averaged, and the sheet's 1,736/s peak is exactly three times that.
Roughly 95 KiB per stored image. That figure reproduces both the 30-day and the 90-day storage columns at every tier.
About 2 Mbps per camera, rounded up to the next standard link speed. That reproduces every network figure in the table, including the 25 Gbps at the top tier.

Images drive the infrastructure, not CPU. At 10,000 cameras the compute requirement fits in ten commodity servers. The 90-day image retention is 438 TB of data before any resilience overhead. Storage is where the money and the risk are.

Reference architecture

What we would build at 10,000 cameras.

Cameras aggregate regionally, cross a 25 GbE WAN, and land on a 100 GbE core. Ingestion, API and event handling scale independently of the database and the image tier.

Compute, event handling and API serving scale horizontally on the same 100 GbE core; the database and the image tier are deliberately separate, because they grow at very different rates.

Compute

320 vCPU is a cluster question, not a server question.

The useful question is not "which server has 320 vCPU" but "how is 320 vCPU distributed so the loss of a node is uneventful".

Eight nodes carry the stated requirement. Ten are installed, so two can be lost — to failure or to patching — without dropping below it.

Per server

CPU40 physical / logical cores
Memory128 – 192 GB
Local storageEnterprise NVMe
NetworkDual 25 GbE
PowerDual supplies
PathsRedundant network paths

Aggregate memory ≈ 1.25 – 1.5 TB, comfortably above the sheet's 896 GB. Memory is the cheapest insurance in this design; do not size it to the minimum.

The central workload is reads and images, not video. Recognition happens at the camera, so the platform ingests plate reads and their associated stills rather than decoding streams. That makes the application tier CPU, memory and I/O bound, and it is why the vCPU figure stays modest while the storage figure does not.

Ingestion

Design for 3,000 events/s, not 1,736.

50 million reads a day is 579 per second averaged, and the sheet's peak is 1,736 per second. Building the ingestion layer to exactly the stated peak leaves nothing for a surge, a backlog replay after a link outage, or a regional site reconnecting with buffered reads.

We size the ingestion path and the event queue for 2,000 – 3,000 events per second, which absorbs those cases without re-architecting. The slider applies the same margin at every tier.

Clustered message queue so a broker failure does not drop reads.
Replay from the queue, so a slow consumer creates a backlog rather than data loss.
Regional buffering at the edge, so a WAN outage defers reads instead of discarding them.

Network

A 100 GbE core against a 25 Gbps requirement.

The sheet calls for 25 Gbps at 10,000 cameras. We would not build a 25 Gbps core to carry a 25 Gbps requirement — a network running at 90–100% of its rated capacity has no room for a rebuild, a bulk export, or a retention migration happening at the same time as normal traffic.

Core100 GbE
Server uplinksDual 25 GbE
Regional aggregation25 GbE
Sheet requirement25 Gbps
Headroom at the core≈ 4×

Storage

This is the part that decides the budget.

Database and image storage have almost nothing in common except that both are called storage. We separate them, and we never provision a 438 TB requirement with 438 TB of disk.

The database is small and fast; the image tier is enormous and sequential. Sizing them as one number is the most common and most expensive mistake at this scale.

Retention

Retention is a legal decision with a hardware bill attached.

Nothing else on this page moves the storage figure as far, and in most jurisdictions the number is not yours to choose freely. Read it off the statute and the records schedule first, then size the cluster to it.

Four classes of data, four different rules

The most common and most expensive mistake is applying a single retention period to “LPR data” as though it were one thing. It is four things, and only the first is contentious.

Non-hit reads

Plates that matched nothing — upwards of 99% of the volume, and the whole of the privacy debate. This is what a statutory limit governs, and what the calculator above sizes.

Hit and BOLO matches

A plate that matched a watchlist is investigative product, not bulk collection. It belongs on the agency’s existing evidence and case records schedule, which is usually measured in years.

Reads pulled into a case

Exported to the case file under a legal hold, so the purge cannot reach them. If a retention job can delete evidence, the problem is no longer privacy — it is spoliation.

Audit logs

Who searched, when, and under what authority. Retain these longer than the reads themselves. If misuse is alleged in month six and the accountability record expired with the data, nothing can be established either way.

Alerting needs almost no retention at all. A watchlist match happens at the moment of the read. Long retention serves only retrospective investigation — so the retention argument is really an argument about how far back a search should reach, not about whether the system works.

What the states require

Verify every figure against the current statute before you rely on it. This table is a compiled orientation aid, not legal advice and not a compliance reference. State LPR statutes are amended frequently, several of these were amended in the last few years, and the citation is given on every row so the text itself can be checked. Compiled August 2026.

Jurisdiction	Limit on non-hit reads	Citation
New Hampshire	Effectively immediate — minutes	N.H. Rev. Stat. § 261:75-b
Maine	21 days	29-A M.R.S. § 2117-A
Minnesota	60 days	Minn. Stat. § 13.824
Montana	90 days	Mont. Code Ann. § 46-5-118
North Carolina	90 days (state agency systems)	N.C.G.S. § 20-183.30 et seq.
Tennessee	90 days	Tenn. Code Ann. § 55-10-302
Arkansas	150 days	Ark. Code Ann. § 12-12-1801 et seq.
Nebraska	180 days	Neb. Rev. Stat. § 60-3,222 et seq.
Utah	9 months	Utah Code § 41-6a-2003
Maryland	1 year	Md. Code, Pub. Safety § 3-509
Vermont	18 months	23 V.S.A. § 1607
Georgia	30 months	O.C.G.A. § 35-1-22
Florida	3 years	Fla. Stat. § 316.0778
California	No statutory cap — but a published usage and privacy policy must state one	Cal. Civ. Code § 1798.90.5 et seq. (SB 34)
Most other states	No general statutory cap — set by agency policy and the records retention schedule	—

The spread is the point: the same system, lawfully operated, holds non-hit reads for minutes in one state and three years in another. A platform sold across jurisdictions cannot have one hard-coded retention period, and a buyer comparing quotes should establish which number the quote was sized against.

Outside the United States

United KingdomNational ANPR Data Centre: 1 year, with access to anything older than 90 days requiring elevated authorisation
European UnionNo fixed period — Law Enforcement Directive 2016/680 requires a documented, justified limit and periodic review
CanadaProvincial privacy regulators have pushed toward prompt deletion of non-hit reads

The UK two-tier model is the one worth copying. Keep a longer tail, but gate the older portion behind a higher approval. It preserves the cold-case capability without leaving a year of everyone’s movements openly searchable day to day — and it is straightforward to enforce at the access layer rather than at the storage layer.

What each period costs at 10,000 cameras

At 50 million reads a day the image tier grows by 4.9 TB every day. Retention multiplies that, close to linearly.

Retention	Image data	Provisioned at 1.35×	Where it applies
30 days	146 TB	≈ 200 TB	Common agency policy default
90 days	438 TB	≈ 600 TB	Montana, North Carolina, Tennessee
180 days	876 TB	≈ 1.2 PB	Nebraska
1 year	1.78 PB	≈ 2.4 PB	Maryland; UK national tier
18 months	2.66 PB	≈ 3.6 PB	Vermont
30 months	4.44 PB	≈ 6 PB	Georgia
3 years	5.33 PB	≈ 7.2 PB	Florida

Going from 90 days to a year roughly quadruples the image tier. That is the single largest lever on this page — larger than camera count, server count or network design — and unlike those, it is usually decided by someone who never sees the storage quotation.

Keep tolling separate

Where the same corridor carries both a tolling function and a public-safety function, the two datasets should not be one dataset. Toll transaction plates belong to the billing and dispute window — typically 30 to 90 days after settlement — in a separate store with separate access control. Merging them is how a revenue system quietly becomes a surveillance system that nobody approved, and it is the version of this that ends up in front of an oversight committee.

Engineering and policy guidance, not legal advice. The binding answer is the statute where the system is deployed, the agency’s own records retention schedule, and any conditions attached to federal grant funding. Where reads are held as criminal intelligence rather than as bulk collection, 28 CFR Part 23 applies as well — and non-hit reads generally do not meet its reasonable-suspicion standard for retention.

Resilience

What a national deployment carries beyond the sizing sheet.

Load balancing

A redundant pair in front of the API cluster, so a balancer is never a single point of failure.

Event processing

A clustered message queue with replication, sized for burst rather than for the average.

Database

Primary with replicas and a tested failover path — not a documented one, a rehearsed one.

Backup

Separate storage and, preferably, a separate site. A backup on the cluster it protects is not a backup.

Disaster recovery

A second location, with the recovery objective agreed in writing before the build, not after an outage.

Compute headroom

N+2 at the application tier, so patching and a node failure can coincide without a capacity conversation.

Camera support

Supported models, by integration tier.

Tiers describe integration status, not camera quality. A Tier 3 device may be an excellent camera that we have simply not yet validated against this platform.

Tier	Status	Models
Tier 1	Production	Hikvision iDS-2CD7A46G0/P-IZHS YMHK NC612-VB432-LDR
Tier 2	Existing receiver / integration	Hikvision iDS-TCE900-A Hikvision iDS-TCM403-BI Hikvision iDS-2CD7A26G0/P-IZHS
Tier 3	Integration validation required	Axis P1465-LE-3 Dahua ITC415-PW
Tier 4	Development required	Genetec AutoVu SharpV

Because recognition runs at the camera, the model you deploy determines read quality far more than the central hardware does. Tier 1 devices are the ones we would specify for a new build.

Assumptions behind these figures

Sizing is only meaningful with its assumptions attached. These are ours, and they are what the slider computes from:

5,000 reads per camera per day, uniform across tiers. A corridor busier than that scales the whole row proportionally.
Peak at 3× the daily average. A network with a sharper commuter profile should be sized on its measured peak, not this multiple.
≈ 95 KiB per stored image. Higher-resolution capture or a second overview image per read changes the storage tier directly.
≈ 2 Mbps per camera, rounded up to the next standard link speed rather than to the exact figure.
Recognition at the camera. Centrally decoding video is a different architecture with different — and much larger — compute requirements.
Retention as selected in the calculator. Retention is a legal and policy decision with a direct, near-linear cost consequence — see the retention comparison.
Between published tiers, vCPU, memory and database follow the curve the sheet describes — the per-camera requirement falls as the deployment grows. Reads, peak, storage and network are exact at every point on the slider.

These are planning figures, not a quotation. A production design should be validated against your measured read volumes, your retention policy, and your resilience requirements before procurement.

Next step

Bring your camera count and your retention policy.

We will size the cluster, the network and the storage tier against your corridor rather than against a table.

Request a sizing review Intelligent Traffic overview

Products

Industries

Resources

Company