CUSTOMER STORY · VECTOR SEARCH BENCHMARK
Mcredit: Benchmarking MongoDB Atlas Vector Search for eKYC deduplication.
MongoDB Atlas · Vector search · eKYCAT A GLANCE
The project at a glance.
Mcredit needed to evaluate whether vector search could support 1:N face deduplication for an eKYC workflow. A customer-developed model converts a face image into a 1024-dimensional vector, which must be compared with the existing vector repository to detect a potential duplicate.
The POC separated database and search resources and used two test environments: a 10-million-vector workload for latency, throughput, stability and index behavior, and a 1-million-vector workload for recall, dimensionality and quantization tests.
POC validation
- Measured HNSW query behavior against exact nearest-neighbor search under controlled test parameters.
- Ran sustained-load testing and monitored latency, errors and search-process memory behavior.
- Compared float32 and scalar quantization to quantify memory savings against retrieval-quality loss.
Interpretation boundaries
- Most benchmark data was synthetic and describes the POC environment, not Mcredit production volume.
- Recall measures HNSW fidelity to exact search, not facial-recognition accuracy.
- The full-index rebuild missed its estimated 15-minute target and remains an explicit operating consideration.
ABOUT MCREDIT
Identity deduplication makes vector-search quality a decision boundary, not a convenience feature.
In the evaluated eKYC flow, Mcredit’s embedding model produces a face vector that is searched against the existing repository to identify a possible duplicate identity or fraud case.
Because the vector result can directly influence the deduplication decision, the POC emphasized retrieval fidelity, stable latency and predictable memory behavior rather than optimizing storage at any cost.
1:N matching
Search a new face vector against an existing identity repository.
Dedicated search tier
Isolate HNSW indexing and queries from database writes.
Technical recall
Compare approximate results with exact nearest-neighbor ground truth.
Sizing evidence
Relate vector format and index size to search-node memory.
TitanBases evaluated MongoDB Atlas Vector Search under controlled benchmark conditions and documented both successful criteria and the rebuild-time exception. The customer’s embedding model and business-level recognition accuracy were outside the database POC.
THE CHALLENGE
Latency · Throughput · Stability · Retrieval fidelity
Fast vector search is useful only when approximation remains acceptable for the decision.
The POC target combined P95 latency below 10 ms with at least 100 requests per second, sustained stability and high retrieval fidelity at large vector scale.
The team also needed to understand whether scalar quantization could reduce memory without unacceptable result reordering, and whether full index rebuild behavior aligned with operational expectations.
The dataset was primarily synthetic. System latency, throughput and technical recall are valid benchmark observations for the tested configuration, but they do not establish production data volume or real-world facial-recognition accuracy.
BENCHMARK · TESTED CONFIGURATION
Large-scale approximate search, measured against exact retrieval.
Dedicated search resources allowed query and indexing behavior to be measured independently from the database workload.
These are POC benchmark measurements from the published technical case, not facial-recognition accuracy, production SLA or production-volume claims.
THE SOLUTION
Replica set · Dedicated search nodes · HNSW · Float32
Separate the database path from vector indexing and retrieval.
Application drivers connect to MongoDB database nodes. Vector queries are forwarded to dedicated search nodes, where HNSW indexes are maintained and queried without placing the same CPU and memory pressure on the write path.
Index updates are synchronized asynchronously through change streams. The POC compared HNSW with exact search, varied numCandidates and vector dimensions, and tested float32 against scalar quantization before recommending production sizing.
SOLUTION ARCHITECTURE
POC Architecture · MongoDB Atlas Vector Search
EVIDENCE-BOUNDED TECHNICAL VIEW · DATABASE AND SEARCH TIERS
Separated data and vector-search resources
Customer-developed embeddings and 1:N query orchestration.
MongoDB replica-set nodes store identifiers and image references.
Dedicated HNSW search nodes hold full index replicas in memory.
Exact-search comparison, load testing and quantization analysis.
POC RESULTS · QUALIFIED
Performance and retrieval fidelity passed; rebuild time remained open.
The benchmark exceeded the latency and throughput target and remained stable during soak testing. It also identified a material quantization trade-off and one missed rebuild-time estimate.
QUERY PERFORMANCE
9.85 ms
P95 at 1,255 QPS in the 10M-vector testSTABILITY
0 errors
Observed during the 20h 16m soak runRETRIEVAL FIDELITY
99.37%
Recall@10 for 1M float32 vectors at 1024 dimensionsOPEN CONSIDERATION
41 min
Full 10M-index rebuild versus a 15-minute estimateScalar quantization reduced index memory about 3.3x but Exact Match@10 fell from about 95% to about 41%. Float32 was retained for this decision-sensitive workload.
TECHNOLOGIES
The MongoDB Atlas components and benchmark methods used in the POC.
Production sizing depends on actual vector volume and the requirement that each search node hold a full index replica in memory.
DATABASE
VECTOR SEARCH
TEST CONFIGURATION
VALIDATION
PRODUCTION READINESS
Size from real vector volume, then validate incremental indexing and business accuracy.
The next steps are to confirm production vector scale, test incremental indexing and evaluate the customer embedding model against labeled real-world images. Those checks are distinct from the database POC.
POC EVIDENCE · NOT A PRODUCTION SLARELATED CAPABILITIES
RELATED CASE STUDIES
Explore more stories.
RELATED INSIGHTS
engineering insight
AI for Financial Services in Vietnam: TitanBases Visits FintechAI and AWS in Ho Chi Minh City
A working visit to FintechAI in Ho Chi Minh City gave TitanBases a closer view of how AI initiatives in Vietnam's financial-services sector are evolving from individual use cases toward production-ready systems, data platforms, infrastructure, and enterprise integration.
Sep 25, 2026
engineering insight
MongoDB Atlas Vector Search for Large-Scale eKYC Deduplication: Lessons from a 10M-Vector POC
Large-scale identity matching requires more than fast vector search. This engineering insight examines latency, throughput, recall, index behavior and quantization trade-offs observed while evaluating MongoDB Atlas Vector Search for a 10-million-vector eKYC workload.
Sep 21, 2026
engineering insight
Game Backend as a Service: Khi nào nên PoC AWS và MongoDB cho game online?
Game backend không chỉ là API. Bài viết này giúp đội game xác định phạm vi PoC thực tế cho matchmaking, game session, dữ liệu người chơi và vận hành trên AWS cùng MongoDB.
Oct 9, 2026
Prepared by TitanBases Engineering Team
TitanBases engineers share practical guidance from cloud, data and AI delivery work, with technical review focused on production architecture, security and operations.
YOUR NEXT WORKLOAD