Ring's semantic video search stores 100–200 billion embeddings, takes in about 2 billion new embeddings a day, and holds 140–150+ TB of data across 3 PostgreSQL clusters. It serves billions of read requests daily across 4 continents and 9 AWS Regions, against a latency target of under 200 ms at p50 and under 2 seconds worst case. The AWS Database Blog reports production latency of about 200 ms at p50 and about 600 ms at p95 and p99, with occasional spikes to 7–8 seconds.
As Ring's engineers put it: "We use PostgreSQL as a vector database."
Ring needed natural-language queries such as "a dog in my backyard," "a package delivery" or "someone wearing a blue shirt" to surface the right footage from days or weeks of recordings. Traditional metadata-based search relying on tags, timestamps or manual annotations could not support this. The system also had to ingest in real time without degrading query performance, isolate each user's data, and handle event-driven traffic spikes such as Halloween, when doorbell activity surges.
The team evaluated purpose-built vector databases, a custom approximate nearest neighbor pipeline with Amazon S3 as the embedding store, and RDS for PostgreSQL with pgvector. Vector databases were prohibitively expensive at this scale, and the S3 prototype's round-trip latency consistently exceeded the sub-2-second SLA. The engineers already had deep PostgreSQL operational expertise.
Videos from Ring devices are stored in Amazon S3, and S3 event notifications trigger Amazon SQS queues that buffer incoming requests and decouple ingestion from processing. The CLIP model, running on GPU-accelerated Amazon ECS instances, extracts frames at regular intervals and generates a 768-dimension embedding for each frame, which RDS for PostgreSQL with pgvector stores. At query time the text is converted into an embedding with the same CLIP model, and PostgreSQL ranks results using pgvector's dot-product distance operator.
Ring creates a dedicated table partition for each user, identified by user ID, device ID and model version, so a query scans only that user's partition of roughly 1 GB. Ring deliberately uses no vector indexes: instead of HNSW or IVFFlat, it relies on brute-force parallel sequential scans within each partition because the use case demands 100% recall. Setting max_parallel_workers_per_gather to 16 raised EBS throughput from about 50 MB/s to 489–590 MB/s. Embeddings are stored as halfvec, and a weighted algorithm assigns each device to a cluster, with the assignment kept in Amazon DynamoDB.
After two months in production, latencies for certain queries rose above 10 seconds because data was not in PostgreSQL's shared buffer cache. Automated pg_prewarm scripts brought a cold instance from about 10,500 ms to under 300 ms, and Ring also relies on RDS Read Optimized Instances. Clusters use RDS Multi-AZ for failover, with monitoring in Amazon CloudWatch.