1 / Scope the search
Use supported filters such as finger position, record scope or event time to reduce unnecessary work.
The latest product update on this page is currently in English. Navigation and account services remain available in your selected language.
Sentinel ID · National identity & operationsExplore all four products →
Scale
Plan from a pilot to 10 billion people
Explore record volumes, search roles, cameras and storage in one scaling plan. The calculator supports up to 10 billion people; its outputs are engineering projections to validate on the intended hardware.
Open the capacity planner10Bpeople at the planner’s maximum
100Btemplates at ten fingers per person
10Bfaces at one record per person
Separatecamera, evidence and database sizing
A selectable planning range is not a claim of deployed or benchmarked capacity. Large-scale acceptance requires representative performance, accuracy and recovery testing.
How a search scales
Narrow candidates, compare, then review
2 / Retrieve candidates
A configured index can produce a shortlist. Measure its recall and behaviour against representative records.
3 / Compare across roles
Distribute configured search work across appropriate processing roles and merge the resulting scores.
4 / Review the evidence
An authorised reviewer checks candidates against source records and supporting evidence before a decision.
The exact deployment topology, index configuration, redundancy and performance targets must be agreed for the project. Index recall and exact-comparison latency are separate acceptance questions.
Scaling architecture
Size each workload for the job it does
| Role | Scaling approach | What to measure |
|---|---|---|
| Fingerprint search | Gallery partitions, candidate retrieval and exact comparison workers, with a replication plan. | Templates, memory, concurrent searches, candidate recall and latency. |
| Face search | Partitioned descriptors and configured search workers. | Record size, index overhead, recall and actual processing time. |
| Camera ingestion | Capture sources and ingestion workers sized to the accepted frame and event rate. | Bursts, backlog, retries, bandwidth and alert-to-review delay. |
| Application and API | Configured application roles behind an appropriate traffic-management layer. | Concurrent users, response latency and failover behaviour. |
| Database and event history | Indexes, retention and a tested partitioning and replication strategy. | Read/write mix, index size, replication lag and recovery. |
| Evidence and files | Organisation-controlled file or object storage, with retention and backup policies. | Image and clip size, sustained writes, access latency and restore time. |
Size your deployment
Plan for up to 10 billion people
Move the people slider from 1 million to 10 billion. The planner derives fingerprint templates and face records, then estimates search-role resources using the assumptions below. These are indicative planning calculations, not measured deployment capacity.
1 million10 billion people
At the maximum: 10 billion people × 10 fingers = 100 billion fingerprint templates. The face assumption is one record per person. Adjust the record sliders independently if your plan differs.
1M100B templates
One template per enrolled finger. Multiple enrolments or versions increase the record count.
1M10B records
66estimated servers for the displayed search roles
—full search of every fingerprint
—search when the finger is known (scanners)
| Role | Servers | Each server |
|---|---|---|
| Fingerprint matchers (two copies) | 40 | 64 cores · 512 GB RAM · 2 × 960 GB SSD |
| Fingerprint shortlist index (memory estimate) | 10 | 64 cores · 512 GB RAM · 2 × 3.84 TB NVMe |
| Face vector index (shards × 2 copies) | 8 | 64 cores · 256 GB RAM · 2 × 3.84 TB NVMe |
| API servers and search coordinators | 8 | 32 cores · 128 GB RAM · 2 × 960 GB SSD |
| Load balancers | 2 | 16 cores · 64 GB RAM |
- Fingerprints held in memory, per copy—
- Range of a full search—
- Theoretical searches/day, finger known—
- Theoretical full searches/day—
- Face search—
- Biometric records in the database (three copies)—
Planning assumptions: 1.7 kB of matcher memory and 525 bytes of shortlist index per fingerprint; 340 GB usable per 512 GB search server; two matcher and face copies; 100,000 to 200,000 fingerprint comparisons per second per core on a 64-core server; one billion face descriptors per shard; three database copies. Timing and daily search figures are arithmetic projections and omit real contention, failures and network overhead beyond the stated allowance. Shortlist latency and recall are not predicted. Camera, database, file storage, recovery, indexing replicas and operating overhead require separate sizing. Replace these assumptions with measurements on the target hardware.
Camera and evidence sizing
People are only one part of the workload
Capture workload
Cameras × captures per day × average image size gives a raw daily image-storage estimate. Full video requires a separate bitrate calculation.
Retention and recovery
Add the retention period, indexes, metadata, replicas, backups and growth headroom. Test a restore into an isolated recovery environment.
Operational workload
Plan concurrent queries and alert review, not just records at rest. Measure bursts and what happens when a connection or processing role fails.
Acceptance benchmark
Make the target measurable
- Load a representative gallery and record the data distribution.
- Agree percentile latency and concurrent-search targets.
- Measure false matches, misses and shortlist recall.
- Sustain the intended camera and event load, including bursts.
- Exercise component failures and verify recovery behaviour.
Read the design and sizing notes
Use the documentation as a starting point, then record the project-specific architecture and benchmark results.