Ring built a semantic video search system on Amazon RDS for PostgreSQL with the pgvector extension that stores 100–200 billion vector embeddings across 3 PostgreSQL clusters holding 140–150+ TB of data, ingests roughly 2 billion new embeddings per day, and serves billions of read requests daily across 9 AWS Regions on 4 continents while holding query latency under 200ms p50 and under 2 seconds worst case.
"Traditional metadata-based search—relying on tags, timestamps, or manual annotations—could not support natural-language queries," the Ring engineering team wrote. Their AI Video Search converts video frames into vector embeddings using the Contrastive Language-Image Pre-training (CLIP) model running on GPU compute, then matches natural-language queries like "package delivery" or "someone wearing a blue shirt" against those embeddings to surface relevant footage from days or weeks of recordings for millions of customers worldwide.
Before settling on an architecture, the Ring team evaluated three options and rejected two. Purpose-built vector databases were ruled out as prohibitively expensive at 100–200 billion embeddings with ~2 billion added daily, and because Ring's workload is almost exclusively dense-vector retrieval rather than hybrid keyword-plus-vector search. A custom ANN pipeline that stored embeddings in Amazon S3 and pulled them down to compute at query time worked correctly but consistently blew past Ring's sub-2-second end-to-end SLA on round-trip latency. The team summed up the resulting architectural choice this way: "We use PostgreSQL as a vector database." The architecture consolidates relational and vector workloads into a single operational tier, getting native approximate-nearest-neighbor search via hierarchical navigable small worlds (HNSW) or Inverted File Flat (IVFFlat) indexing inside the database engine the team already operated.
The ingestion pipeline uses Amazon S3 buckets to store raw video, S3 event notifications trigger Amazon Simple Queue Service queues to buffer incoming requests, and the CLIP model running on GPU instances generates the embeddings that pgvector stores and indexes. This event-driven decoupling is what lets the system absorb traffic spikes such as Halloween, when doorbell activity surges, and lets new embeddings land in the index without degrading query performance.
That consolidation let Ring avoid introducing a separate vector database system with its own failure modes, monitoring gaps, and operational runbooks. By choosing RDS for PostgreSQL with pgvector, Ring "transformed what could have been a costly infrastructure expansion into a capability extension" — meeting production requirements for cost, latency, and reliability without adding new operational surface area while preserving headroom to scale beyond a billion embeddings without an architectural redesign.