Vector databases, and when a column will do

A vector database stores embeddings and answers nearest-neighbour questions over them, and the thing you are really buying is an index that trades recall against latency and memory, which is why the honest question is not whether to use one but whether your scale needs a dedicated one.

Most projects that reach for a vector database would be finished sooner with a vector column in the database they already run. Some would not. The difference is measurable before you choose.

What is actually stored

An embedding is a list of numbers produced by a model, positioned so that things with similar meaning sit near each other. The database holds those lists and answers one question well: which of these millions of points is closest to this one. Everything a vector store markets is downstream of that single operation, and if your problem is not a nearest-neighbour problem, none of it applies.

The index is the product, and it is a trade

An exact search over a million vectors is slow, so every vector store builds an approximate index instead. Approximate is the load-bearing word: the index returns most of the right answers most of the time, and how close to all of them depends on parameters you set. Turn them toward accuracy and queries slow and memory grows. Turn them toward speed and results quietly get worse. Nobody is hiding this and almost nobody measures it, which is how a search that feels fast ends up being wrong in ways users notice before you do.

The threshold where a column is enough

Postgres with a vector extension handles small collections comfortably on hardware you already pay for, in a system your team already knows how to back up, monitor and restore. A dedicated store earns its place when the collection or the query rate outgrows that, or when you need filtering and sharding it cannot do. Adding a second database has a real running cost in operations rather than licence fees, and that cost arrives whether or not the scale ever does.

Changing the embedding model invalidates everything

Embeddings from one model are not comparable with embeddings from another, so the day you upgrade the model, every vector you have stored becomes meaningless against new ones. The fix is to re-embed the entire collection, which costs time and money proportional to its size, and to do it without a window where half the index is old and half is new. Plan the migration path when you choose the model rather than when the better model ships.

The failure you will actually hit

Not the database falling over. A query that returns confident, fast, plausible results that are subtly not the closest matches, because the index parameters favour speed or because the collection has drifted. Measure recall against a small exact search on a sample, deliberately and regularly. It is the one number that tells you whether the search is doing its job, and it is the number almost nobody looks at until somebody complains about results.

Live, right now, on this page

Market	Price	Funding	24h volume
BTC	$86,364.50	0.0013%	$522,866,341
ETH	$2,750.85	0.0013%	$301,603,802
SOL	$118.01	0.0013%	$94,709,358
HYPE	$96.97	0.0013%	$3,938,323

Read from a live market as this page rendered. Read at 2026-09-23 02:12 UTC; accurate as of that time and not afterwards.

Describe something and watch it get built.

Open the builder, or start from a working app and change it.

Common questions

Do I need a vector database, or is Postgres enough?

For a small collection on hardware you already run, the vector extension in Postgres is usually enough, and it keeps your data in one system your team can already back up and restore. A dedicated store earns its place when the collection or the query rate outgrows that, or when you need filtering it cannot do. The cost of the second system is operational rather than financial, and you pay it from the day you add it.

What happens when I change the embedding model?

Every vector you have stored stops being comparable with the new ones, because embeddings from different models do not share a space. The whole collection has to be re-embedded, which costs time and money in proportion to its size, and it needs doing without a window where half the index is old. Decide how that migration will work when you pick the model, not when a better one arrives.

Why does my similarity search feel fast but return the wrong things?

Because the index is approximate by design and its parameters are probably tuned toward speed. It returns most of the nearest matches most of the time, and how close to all of them is a setting rather than a guarantee. Measure recall against an exact search over a sample: it is the one number that says whether the search is doing its job, and results degrade quietly without it.