Do I need a vector database with filtering by metadata?

Not always.

You need a vector database with metadata filtering if your app must do semantic search plus structured constraints at query time, for example:

• “Find similar documents from last week”
• “Retrieve only chunks for tenant A”
• “Search recipes about pasta and only include Italian cuisine”
• “Recommend products semantically, but only those in stock and under $50”

In those cases, filtering by metadata is very useful because it lets you combine:

1. Vector similarity = “close in meaning”
2. Metadata filters = “must match these conditions”

You probably do need it if:

• You have many documents and need fast retrieval
• You want to enforce access control / multi-tenancy
• You need filters like author, date, category, language, price, location, status, etc.
• You want an efficient RAG system where only relevant subsets are searched

You may not need it if:

• You only have a small dataset
• You can filter in application code after retrieval
• You don’t need structured constraints
• You’re using embeddings only for clustering, classification, or rough similarity

Alternatives

Depending on your setup, you might use:

• Plain relational DB + embeddings column if search scale is modest
• Search engine with vector support like Elasticsearch/OpenSearch
• Postgres with pgvector for many practical use cases
• Dedicated vector DB like Pinecone, Weaviate, Milvus, Qdrant if you need scale and fast filtering

Rule of thumb

If your retrieval logic is:

“Find the most similar items, but only among items matching certain fields”

then yes, a vector database with metadata filtering is often the right tool.

If you want, I can help you choose between Postgres/pgvector, Elasticsearch, and a dedicated vector DB based on your specific use case.