vector storage is not your new database religion

Every RAG prototype wants a vector database before it wants a data model.

That is usually backwards.

The first hard question is not which ANN index has the nicest benchmark chart. It is whether anyone has decided how fresh the embeddings must be, who owns deletes, where tenant boundaries live, how metadata filters are tested, what gets rebuilt after a schema change, and whether the source document is still the source of truth after a chunk has been embedded.

The database choice matters.

But it is not the religion.

The more interesting shift is that vector search is being absorbed by platforms teams already run.

AWS made S3 Vectors generally available and is explicitly selling vector storage as part of object storage. Google documents vector indexes inside BigQuery. OpenSearch treats vectors as part of a search platform that already has lexical search, hybrid ranking, ingestion, and operations muscle. Cloudflare Vectorize puts retrieval close to Workers and edge applications. Postgres keeps getting better vector-search ergonomics through pgvector.

That does not mean specialized vector databases are dead.

It means the lazy default is dying.

vectors are becoming storage policy

For a while, the shape of the conversation was simple.

You had text. You embedded it. You put vectors in a vector database. You queried nearest neighbors. You passed chunks to a model. You called that architecture.

That was fine for demos.

Production systems are less polite.

They ask whether the vector is hot, warm, or cold. They ask whether a query needs lexical constraints, tenant filters, recency rules, security labels, or exact source attribution. They ask what happens when a user asks to delete data. They ask whether yesterday's embedding model and today's embedding model can live in the same index. They ask whether a failed ingestion job left a half-updated semantic view of the business.

Once those questions show up, vector search stops being an AI feature and starts being data infrastructure.

That is why S3 Vectors is notable. The point is not that object storage suddenly became a replacement for every vector database. The point is that a hyperscaler is saying, out loud, that there are vector workloads where durability, scale, cost shape, bucket-level governance, tagging, PrivateLink, CloudFormation, and integration with higher-level AI services are the product.

That is a storage argument.

Not a model argument.

not every embedding wants the same home

There are at least five different workloads hiding behind the phrase "vector search."

Hot product retrieval is latency-sensitive. It powers search boxes, recommendations, support copilots, personalization, or agent tools that users are waiting on. It needs predictable query latency, aggressive filtering, monitoring, relevance tests, and a clean rollback path when ranking changes break the experience.

Filtered enterprise retrieval is permission-sensitive. It is where most naive RAG architectures quietly break. The user should not retrieve a document they cannot read just because the vector was close. Metadata filters are not garnish. They are part of the authorization model.

Cold semantic archive is cost-sensitive. It has a lot of vectors, lower query frequency, and a different relationship with latency. Paying hot-index prices for everything because a prototype started that way is just another cloud bill with better cosine distance.

Warehouse-native retrieval is analytics-sensitive. When vectors live near BigQuery-style analytical data, the useful question is often not "can I build a chatbot?" It is "can I combine semantic search with governed datasets, SQL workflows, partitioning, and business metrics without exporting another shadow copy?"

Edge retrieval is placement-sensitive. Cloudflare Vectorize is interesting because it puts vector lookup near the edge application runtime. That is not the same design point as a centralized retrieval service for internal documents. It has different latency, locality, deployment, and cache assumptions.

Postgres retrieval is ownership-sensitive. If the object already lives in Postgres, the access control logic lives nearby, and the vector feature is modest, pgvector may be the most honest answer. Not because Postgres wins every ANN benchmark. Because moving the embedding somewhere else may create more operational debt than the ranking benefit is worth.

These are different systems.

They deserve different defaults.

object storage does not kill vector databases

It is tempting to make this a death-of-vector-DB story.

That is lazy too.

Specialized vector databases still matter when vector search is the core product surface, when teams need sophisticated index management, high-throughput low-latency retrieval, advanced hybrid ranking, multi-region serving patterns, or operational features built specifically around retrieval. Search engines still matter when lexical, semantic, filtering, and ranking pipelines are intertwined. Databases still matter when transaction boundaries and local ownership dominate. Warehouses matter when retrieval is part of analytical work. Object storage matters when scale, durability, lifecycle, and cost tiering dominate.

The right conclusion is less dramatic and more useful:

vector storage is becoming tiered.

That is what happens to important data types. They stop living in one fashionable service category and start appearing across the stack. Logs did this. Metrics did this. Documents did this. Feature stores did this. Now embeddings are doing it.

The team that understands the tiers will make better tradeoffs than the team that treats "vector DB" as a checkbox.

the metadata is the contract

The vector is the least interesting part of the object.

The metadata tells you who may see it, where it came from, when it was embedded, which model created it, which chunking strategy was used, what source version it represents, when it expires, how it should be filtered, whether it is safe for a given tenant, and whether it is eligible for a given product surface.

If that metadata is sloppy, retrieval quality becomes a debugging séance.

You will get answers from stale documents, missing deletes, wrong tenants, old embeddings, broken chunking, duplicate sources, or index rebuilds no one remembers starting. The model will look guilty because the answer is bad, but the real bug will be the retrieval contract.

This is where boring platform engineering helps.

Name the source of truth. Version the embedding model. Version the chunker. Store the source pointer. Track the ingestion job. Record the index version. Make deletes observable. Make rebuilds repeatable. Make filter behavior testable. Put cost attribution somewhere finance can find it. Decide which parts are backup data, derived data, cache data, or regulated data.

Do that before arguing about vector database logos.

retrieval quality is now an ops metric

Most teams know how to monitor latency, error rate, queue depth, storage growth, and cost.

Fewer teams know how to monitor recall drift.

That gap is going to hurt.

A vector index can be technically healthy and product-broken. Queries return quickly. APIs are green. The agent still uses the wrong policy document because the newer document was embedded with a different model, or because metadata filters pruned the right result, or because a cheaper index parameter made the recall acceptable in aggregate and terrible for one critical class of query.

Production RAG needs relevance tests the way payments need reconciliation tests.

Keep a corpus of known questions. Track expected sources. Run them against every index rebuild and embedding-model change. Measure filtered recall, not just nearest-neighbor speed. Watch how many answers cite stale sources. Watch how often the retrieval set crosses tenant, product, region, or security boundaries. Make index changes reviewable like schema migrations.

If you cannot test retrieval, you do not have retrieval infrastructure.

You have vibes with a vector column.

the checklist before you add another vector service

Before adding a new vector platform, answer these questions:

• What is the source of truth for each embedded object?
• What freshness SLA does each retrieval surface need?
• How do deletes propagate, and how do you prove they propagated?
• Which metadata fields are mandatory for authorization and filtering?
• Can tenant filters be bypassed by query shape, fallback search, or hybrid ranking?
• What is the embedding model version, and how do mixed-version indexes behave?
• What is the chunking version, and how are rebuilds triggered?
• Who pays for storage, indexing, and query costs?
• Which vectors are hot, warm, cold, or archival?
• What is backed up: vectors, sources, index definitions, or rebuild pipelines?
• How do you measure recall after an index configuration change?
• What is the rollback plan when retrieval quality drops?

That checklist will not tell you whether to use S3 Vectors, BigQuery, OpenSearch, Cloudflare Vectorize, pgvector, or a specialized vector database.

It will tell you what kind of problem you actually have.

And that is the part most architecture debates skip.

embeddings are production data now

Embeddings used to feel like temporary AI exhaust.

Generate them, store them, query them, move on.

That mental model is wrong now.

Once embeddings decide what an agent sees, what a customer support workflow cites, what a search page ranks, what a compliance assistant retrieves, or what a sales copilot tells a human, they become production data. Derived data, yes. Imperfect data, yes. But still production data.

Production data needs ownership.

It needs lifecycle.

It needs tests.

It needs policy.

Vector storage is not your new database religion. It is another place where the old data-infrastructure questions come back wearing AI clothes.

Ask those questions first.

Then pick the database.

sources

• AWS News Blog: Amazon S3 Vectors now generally available with increased scale and performance
• Amazon S3 User Guide: Working with S3 Vectors and vector buckets
• Google Cloud BigQuery: Manage vector indexes
• OpenSearch Documentation: Vector search
• Cloudflare Vectorize documentation
• PostgreSQL: pgvector 0.8.0 Released
• arXiv: ByteX, a unified AI search engine at ByteDance
• arXiv: Vector Search for the Future

To test my projects, I use Railway. If you want $20 USD to get started, use this link.