Timescale PRISM: Run 100M Vectors on 1/4th Postgres RAM

Dedicated vector search within relational databases has reached a severe hardware boundary: keeping uncompressed Hierarchical Navigable Small World (HNSW) graph indices resident in DRAM forces infrastructure teams to over-provision multi-hundred-gigabyte server instances simply to prevent query thrashing. Timescale’s new open-source extension, pg_vectorsearch, introduces the PRISM index access method, serving 100 million Cohere embeddings at 99% recall in 21 milliseconds on a 128 GiB AWS instance where pgvector HNSW cannot even build. In benchmark disclosures published by Timescale on a 512 GiB instance, PRISM builds the 100M index in 49 minutes—51.4 times faster than HNSW’s 42-hour construction—while reducing index footprint from 180 GB to 25 GB.

The release marks a decisive philosophical retreat from graph-based vector indices across the data infrastructure landscape. While vector database marketing long promised that multi-layer graph traversals were the only path to sub-10ms approximate nearest neighbor (ANN) retrieval, practitioners running production retrieval-augmented generation (RAG) pipelines repeatedly hit an economic wall: DRAM is too expensive to house monolithic graph edge lists, and the moment a graph index spills to NVMe storage, query latency explodes from milliseconds into full seconds.

Why Walking Graphs Stalls Modern CPUs

To understand why graph indices fail at scale, one must look at how modern processor memory subsystems operate. An HNSW index organizes high-dimensional vectors as a multi-layer graph where nodes represent vectors and edges connect nearest neighbors. During query execution, the search algorithm explores the graph via greedy routing, evaluating distance metrics at the entry point and hopping across edges to adjacent nodes until finding a local minimum.

Every hop across an HNSW graph represents an unpredictable pointer chase. The memory address of node B is stored inside node A. Because the CPU hardware prefetcher cannot predict which edge the search loop will follow next, it cannot pull the subsequent cache line into L1 or L2 cache ahead of execution. Every edge traversal triggers a compulsory L3 cache miss or a main memory DRAM access penalty of 60 to 100 nanoseconds. The CPU execution units sit idle, stalled on memory bus arbitration.

When an HNSW index exceeds available DRAM and pages out to NVMe SSDs, the architectural penalty becomes catastrophic. Instead of nanosecond memory stalls, each graph hop triggers an asynchronous 4 KiB random page read over PCIe, incurring 50 to 120 microseconds of latency. Because graph routing requires sequential node exploration where hop N+1 depends strictly on the outcome of hop N, the query engine cannot parallelize these reads.

This bottleneck mirrors the physical constraints explored in our analysis of memory bandwidth bottlenecks under autoregressive load, where memory latency rather than raw compute cycles dictates execution ceilings. In benchmark disclosures published by Timescale on AWS r8i.4xlarge instances (128 GiB RAM), an HNSW index constructed on a larger machine and moved to the smaller host exhibited query latencies exceeding 1,000 milliseconds at 95% recall, completely failing to achieve 99% recall.

The Quiet Collapse of DiskANN and Graph Reachability

The industry attempted to patch this flaw by moving graphs to disk using algorithms like Microsoft Research’s DiskANN. In 2024, Timescale themselves adopted this architecture in pgvectorscale. However, real-world deployment exposed a fundamental topological failure mode: graph reachability collapse.

On diverse, skewed, or low-dimensional datasets, graph construction heuristics frequently create isolated or weakly connected subgraphs. Queries entering the graph from distant entry nodes become trapped in local topological basins, entirely unable to reach the true nearest neighbors. Unlike slow queries, which surface in telemetry dashboards, reachability collapse silently degrades retrieval recall without triggering database errors.

Tuning graph construction parameters (M, efConstruction, alpha) provided heuristic band-aids on some datasets while exacerbating recall loss on others. In their architectural disclosure for pg_vectorsearch, Timescale confirmed that pgvectorscale has entered maintenance mode, abandoning graph traversal in favor of partitioned clustering.

This transition validates the architectural shift detailed in our teardown of the Turbopuffer inverted index pivot, which demonstrated that serverless retrieval engines achieve superior cost and recall by pairing secondary inverted indices with sequential streaming rather than keeping stateful graphs in memory.

Inside PRISM: Hierarchical Centroids and Streaming Partitions

PRISM (Partitioned Routing Index for Similarity Matching) solves the memory wall by discarding graph edges entirely. Drawing inspiration from Google’s ScaNN, Microsoft’s SPANN, and SPFresh, PRISM structures vector space into a two-tier inverted file index (IVF):

A hierarchical k-means centroid tree partitions the vector universe into dense geometric clusters. The centroid pages are stored directly in PostgreSQL’s standard shared_buffers cache. Because centroid pages are accessed on every query, PostgreSQL naturally keeps them warm in DRAM without requiring specialized caching layers.

Each cluster leaf references a posting list containing densely packed, quantized vector representations alongside heap tuple identifiers (TIDs). When a query executes, it traverses the small centroid tree in shared buffers to locate the nearest cluster centroids, and then performs a high-bandwidth linear scan across those specific posting lists.

Linear memory scans fundamentally transform the hardware equation. Because posting lists are laid out contiguously on disk pages, the operating system and CPU hardware prefetchers stream blocks sequentially into memory. Instead of waiting for scattered random reads, modern x86 and ARM processors saturate their SIMD execution units—utilizing AVX-512, AVX2, or ARM NEON instructions—evaluating distance approximations across multiple candidate vectors in parallel.

The Silicon Arithmetic of RaBitQ Pruning

Scanning millions of vectors sequentially would still saturate memory bandwidth if vectors were stored in uncompressed 32-bit float format (1,536 bytes per 384-dimensional vector). PRISM eliminates this bottleneck by integrating RaBitQ (Randomized Binary Quantization).

RaBitQ quantizes each vector dimension down to a single bit (0 or 1), reducing memory consumption by up to 32 times. However, standard binary quantization typically suffers severe recall degradation because cosine distances between binary hypercube projections distort true Euclidean relationships.

PRISM overcomes this through two mathematical breakthroughs:

First, RaBitQ computes a closed-form theoretical error bound for each quantized distance estimation. During the posting list scan, the engine calculates a two-stage filter: an estimated binary distance based on Hamming weight computations executed via hardware popcount instructions, paired with a deterministic error bound derived from the vector’s quantization residual.

If a candidate vector’s lower error bound exceeds the upper bound of the current top-k candidates, the engine discards it immediately without accessing the underlying table heap. Only candidates whose error bounds intersect the top-k margin are retrieved from the PostgreSQL heap for full-precision 32-bit reranking.

To protect against boundary distortion—where a target vector falls near the perimeter of cluster A but belongs to the metric neighborhood of cluster B—PRISM incorporates the SOAR (Spilling Over Adjacent Regions) algorithm from ScaNN, replicating boundary vectors across neighboring posting lists at index build time.

Empirical Benchmark Audit: 100M and 1M Vector Evaluation

The performance divergence between PRISM and pgvector HNSW was evaluated across two primary datasets on AWS EC2 hardware running identical PostgreSQL configurations, as disclosed in Timescale’s engineering release:

The benefits scale downward to common database tiers. On an AWS c8g.large instance (4 GiB RAM), PRISM builds 1 million vectors in 3.1 minutes and answers queries at 99% recall in 9 ms. pgvector HNSW required 21.7 hours to build due to severe memory thrashing during graph linking, consuming 2.05 GB of disk space (versus 280 MB for PRISM) and taking 392 ms per query—a 43.5x latency penalty.

Alpha Operational Hazards and Maintenance Traps

While PRISM’s architectural advantages over graph traversal are decisive, pg_vectorsearch is currently tagged as an alpha release. Engineering teams evaluating it for production RAG systems must account for four concrete operational constraints:

1. Dynamic Insert Fragmentation and Drift

At initial index construction, PRISM writes posting lists contiguously to disk. However, as new rows are inserted via SQL INSERT statements, existing posting pages fill up. The engine allocates new posting pages at the end of the physical file (EOF), creating non-contiguous pointer links.

Over time, this fragmentation degrades sequential SIMD scanning into random disk seeks. Under heavy write churn, query latency drifts upward and recall drops. To restore physical clustering, database administrators must manually invoke SELECT prism_rebalance('index_name') to split oversized partitions, or execute a full REINDEX. Automatic background rebalancing is deferred to the General Availability (GA) release.

2. The Selective Filter Recall Collapse

PRISM currently operates strictly via post-filtering. When a query includes a metadata predicate (e.g., WHERE tenant_id = 42 ORDER BY embedding <-> query_vec LIMIT 10), the index engine first gathers the top-k nearest vector candidates, and only then applies the SQL filter to the returned set.

If the metadata filter is highly selective (matching less than 5% of the table), the candidate pool gathered during the initial centroid scan may contain zero matching rows, causing the query to return an empty result set despite valid matching records existing elsewhere in the table. As detailed in our review of pg-jev SQL LIMIT spend guards, treating query constraints as isolated execution stages creates severe correctness and billing failures in production databases. Timescale has stated that streaming filtering—where the index continuously produces candidates until filter criteria are satisfied—is slated for GA.

3. Dimensionality and Engine Constraints

PRISM imposes a hard structural ceiling of 1,968 dimensions per vector due to page packing layouts. Models producing 2,048-dimensional or 4,096-dimensional embeddings cannot be indexed. Furthermore, pg_vectorsearch requires PostgreSQL 18 or later, preventing immediate deployment on managed hyperscaler environments like AWS RDS or Google Cloud SQL until those platforms support the newest engine releases.

4. VACUUM Space Reclaim Deficit

When records are deleted, PostgreSQL’s VACUUM sets the PRISM_POSTING_FLAG_DELETED flag on the corresponding posting list entry, allowing search scans to bypass it. However, the physical byte space inside the posting page is not reclaimed or compacted, leading to index bloat over time until a manual REINDEX is executed.

Frequently Asked Questions