PGDay Lowlands2026

Building a vector search prototype is easy; keeping it running in production is a completely different problem. When developers push millions of high-dimensional embeddings into PostgreSQL, the physical limits of the database hit hard. Massive vector columns trigger heavy TOAST usage, evict critical data from shared_buffers, and cause storage footprints to explode, usually leaving DBAs to fix the resulting performance degradation.

Using data from real-world experiences, we will expose what actually happens to your infrastructure and query plans when vector tables grow exponentially and analyze the trade-offs between space utilization, query latency and recall.

Finally, we will explore how to shrink the storage and RAM footprint using halfvec (float16) and binary quantization, while measuring the cost to search accuracy.