Supabase recently released a public alpha of their S3-compatible Vector Buckets, a new way to store and query vector embeddings at scale. These vectors are particularly useful for semantic search and RAG with (LLMs, where finding relevant embeddings quickly is critical. Unlike traditional approaches that rely on Postgres-native indexing, such as HNSW or IVFFlat, Vector Buckets offload storage and some computation to an external, S3-style layer. This makes them highly scalable and cost-efficient, especially for applications dealing with millions or billions of vectors.
Below is a detailed comparison of how Supabase Vector Buckets stack up against HNSW and IVFFlat indexes in PostgreSQL:
| Dimension | Supabase Vector Buckets | IVFFlat | HNSW |
|---|---|---|---|
| Type | Managed vector storage | Cluster-based ANN index | Graph-based ANN index |
| Where it runs | External (S3-style storage layer) | Inside Postgres | Inside Postgres |
| Query speed | ⭐ Higher (~300–500 ms) |
⭐⭐ Low (~40–100 ms) |
⭐⭐⭐ Very low (~20–50 ms) |
| Accuracy (recall) | ⭐⭐ Good (~90–95%) |
⭐⭐ Medium (~85–95%) |
⭐⭐⭐ Very high (~98–99%) |
| Scalability | ⭐⭐⭐ Massive (millions–billions) |
⭐⭐ Large (Up to hundreds of millions) |
⭐ Limited by memory (Up to tens of millions) |
| Throughput | ⭐⭐⭐ High (1,000–10,000+ QPS) |
⭐⭐ DB-limited (200–2,000 QPS) |
⭐ DB-limited (100–1,500 QPS) |
| Incremental updates | ⭐⭐⭐ Easy | ⭐⭐ Easier (add to clusters/probes) |
⭐ Costly (graph rebuild needed) |
| Control over algorithm | ⭐ None (abstracted) | ⭐⭐ Partial control | ⭐⭐⭐ Full control |
| Tuning knobs | ⭐ None | ⭐⭐ Some (probes, lists) |
⭐⭐⭐ Many (ef, M, etc.) |
| Index build time | ⭐⭐⭐ Managed (secs–mins/10M vec.) |
⭐⭐ Faster (mins/10M vec.) |
⭐ Slow (mins–hrs/10M vec.) |
| Memory usage | ⭐⭐⭐ Low (index offloaded) |
⭐⭐ Medium (~10–50 B/vec.) |
⭐ High (~50–200 B/vec.) |
| Storage cost | ⭐⭐⭐ Cheap (~$0.02–0.05/GB) |
⭐⭐ Moderate (~$0.05–0.10/GB) |
⭐ Expensive (~$0.10–0.20/GB) |
| Metadata filtering | ⭐⭐⭐ Supported | ⭐⭐⭐ Supported | ⭐⭐⭐ Supported |
| Query interface | SDK / API (queryVectors) |
SQL + tuning params | SQL (ORDER BY <->) |
| Best for | Massive, scalable vector storage | Balanced performance at scale | Real-time, high-accuracy search |
