What Is a Vector Database? Do You Even Need One?

A vector database stores vectors, the numeric representations that embedding models produce, and answers one question quickly: which stored vectors are closest to this query? That question is the core of search, recommendation and retrieval features. For most bootstrapped founders the useful answer is to start with Postgres and pgvector, then move only when a measured limit appears.

TL;DR

• A vector database stores embeddings and returns the nearest matches to a query vector.
• pgvector adds vector similarity search to Postgres, so vectors sit beside your relational data.
• Exact search gives perfect recall, while an index trades some recall for speed.
• HNSW favours speed and recall over build time and memory; IVFFlat favours faster builds and lower memory.
• Filtering after an approximate index scan can return far fewer rows than you expect.

Disclosure: ZeroRaised publishes this analysis and is a launch site for bootstrapped products. Facts come from the linked sources as checked on 3 Nov 2026; ZeroRaised has no commercial relationship with the companies named.

A vector database is a system that stores vector representations of content and retrieves the vectors closest to a query, usually ranked by cosine, inner product or another distance measure.

What does a vector database actually do?#

A vector is a list of numbers that represents something. An embedding model turns text, an image or a recording into such a list, and items with similar meaning end up close together. The guide to embeddings covers the background.

The database's job is nearest neighbour search: given a query vector, return the closest stored vectors. The pgvector README describes the extension as "Open-source vector similarity search for Postgres" and its pitch is "Store your vectors with the rest of your data."

The real decisions are the distance function, exact or approximate search, and whether the store sits beside your existing data.

How does similarity search work?#

Each row holds a vector. A query supplies another vector, and the database scores stored vectors by distance, sorts them and returns the top matches. pgvector exposes the distance in SQL through operators: <-> for L2 distance, <#> for negative inner product, <=> for cosine distance and <+> for L1 (pgvector README).

SELECT * FROM items ORDER BY embedding <-> '[3,1,2]' LIMIT 5;

The README also lists single precision, half precision, binary and sparse vectors, with L2, inner product, cosine, L1, Hamming and Jaccard distances. Vectors that are close under the chosen measure are similar as far as the system is concerned. That makes the distance function a product decision: cosine and L2 can rank the same items differently.

Should you use exact or approximate search?#

By default, pgvector performs exact nearest neighbour search, which the README says provides perfect recall. Every query compares against every candidate, so recall is not the problem; speed at size is.

Adding an index switches to approximate search, "which trades some recall for speed" (pgvector README). You accept that the top result might not be the true nearest neighbour in exchange for not scanning everything.

For a small product the exact path is often fine and simpler. Test with your own data before adding an index.

HNSW or IVFFlat?#

Both are index types in pgvector, with different trade-offs (pgvector README):

• HNSW builds a multilayer graph. It gives better speed and recall than IVFFlat, but builds more slowly and uses more memory.
• IVFFlat divides vectors into lists and searches the closest subset. It builds faster and uses less memory, but its speed and recall are lower.

Based on those trade-offs, HNSW is a sensible default when latency and recall matter and you can afford the memory. IVFFlat suits tight memory or frequent rebuilds. Neither removes the need to test recall on your own queries.

Why does filtering get worse with an approximate index?#

With an approximate index, pgvector applies a filter after the index scan (pgvector README). The index returns a candidate list, then the filter removes rows that do not match.

The README gives a concrete example: if a condition matches 10% of rows, with HNSW and the default hnsw.ef_search of 40, only about 4 rows match on average.

Iterative index scans, available since 0.8.0, help by fetching more candidates when the filter is selective (pgvector README). If your product always filters by tenant, user or status, test that query on realistic data, not an unfiltered benchmark.

How much storage will the vectors need?#

pgvector stores each vector at 4 bytes per dimension plus 8 bytes of overhead (pgvector README). A 1,536 dimension vector takes 6,152 bytes. A million of them take about 6.2 GB before the index and the rest of the row. That makes dimension choice a cost decision as well as a quality one.

There are index limits: a vector column can be indexed up to 2,000 dimensions, halfvec up to 4,000, bit up to 64,000 and sparsevec up to 1,000 non-zero elements (pgvector README). Check your embedding dimension against those limits before you design the schema.

Do you need a dedicated vector database?#

Usually the answer is no on day one. pgvector gives you vector search with ACID compliance, point-in-time recovery and JOINs on Postgres 13 or later (pgvector README). If you already run Postgres, that is one system to back up and one query language, and embeddings can join to users, documents and permissions without copying data elsewhere.

A dedicated store makes sense when a measured constraint pushes you there: the index no longer fits in memory, query volume needs separate scaling, or you want a managed service with its own operational model. Those are engineering decisions, not category decisions. Move when your numbers say Postgres is the bottleneck.

If you are still working out what goes into the vectors, read the guide to RAG. The same feedback loop also feeds systems that keep learning after deployment, which is where continual learning comes in.

What this means for bootstrapped founders#

1. Start on Postgres. Use pgvector and exact search until you have a reason not to. One database is cheaper to run and easier to reason about than two.
2. Choose the distance function deliberately. Cosine, inner product and L2 are not interchangeable. Match the measure to your embedding model and test retrieval quality on real queries.
3. Measure before adding an index. Compare recall and latency with and without HNSW or IVFFlat. An index is a trade, not an upgrade.
4. Test filtered queries. If every query filters by tenant, benchmark that exact shape.
5. Watch dimensions and storage. At 1,536 dimensions each vector is 6,152 bytes. Half precision or binary vectors can cut the bill if retrieval holds up.
6. Track cost per query. The LLM cost guide covers how to follow the whole task.

Related reading from this week: The NYT Sued Brave. Founders Building on Web Data, Read This.

Where ZeroRaised fits#

ZeroRaised is a launch and discovery site for products built without institutional venture capital or accelerator equity. If you have a product people can try, submit it here; the pricing page explains the current options.

For more practical analysis, join the ZeroRaised newsletter. No promises of traffic or results, just the useful parts.

Sources#

• pgvector README