Do we need a vector database? Not for your first AI feature

Do not adopt yet. Start with pgvector in the Postgres you already run, measure recall and p95 at your real corpus size, and let the numbers justify a second datastore.

When you should buy it anyway.

A library that says no to everything is as useless as one that says yes to everything. These are the conditions under which this purchase is right — and if one of them describes you, stop reading and go and buy it.

• Your corpus is large enough that index build time and memory push the Postgres instance you actually run past comfort — tens of millions of vectors and up is where dedicated stores start earning their keep on operational grounds alone.
• You need retrieval features Postgres does not give you cheaply: namespace-level isolation at scale, hybrid search with managed reranking, or sub-50ms p95 at high concurrency with a hard SLA behind it.
• Your embeddings are genuinely not co-located with relational data — a separate corpus with no tenancy or permission joins. Then the synchronisation argument on this page does not apply to you.

The permission join is the whole architecture

In consumer AI demos, retrieval is a similarity search over one public corpus. In B2B SaaS it is never that. The query is “find the most relevant chunks from documents belonging to tenant 4471 that this user's role can read, excluding anything archived since last quarter”, and every one of those predicates lives in your relational schema. Keep vectors in Postgres and this is one query with an index on it. Split them across two systems and you choose between over-fetching from the vector store and filtering afterwards (which quietly destroys recall) or replicating permission metadata into the vector store (which is the synchronisation problem you were trying to avoid).

That is the argument, and it is architectural rather than financial. The licence saving is real but secondary. The primary saving is that you do not spend the next year fixing bugs of the form “deleted document still appears in AI answers”, which are among the worst bugs a B2B product can ship because they look exactly like a data-leak incident to the customer who reports one.

pgvector is not a toy. It is a mature Postgres extension supported by the managed providers most teams already use, with HNSW indexing, and it participates in transactions — so an embedding written in the same transaction as its document either both land or neither does. That property has no equivalent in a two-store design.

Measure before you migrate

The honest version of this decision is a threshold, not a religion. Dedicated vector databases exist because at sufficient scale, index memory, build time and query concurrency genuinely outgrow a general-purpose database — and when you cross that line, the operational argument flips decisively. The mistake is assuming you are past the line before measuring.

So build the instrument first. Assemble fifty questions with known-good source chunks, and record recall at the top-k your product actually uses, plus p95 latency under a realistic concurrency profile. Re-run both after every chunking or embedding change. That harness costs a day, tells you whether retrieval quality problems are an indexing issue or a chunking issue (usually chunking), and is the only evidence that will make a migration decision defensible later.

When you do migrate, migrate for a stated reason with a number attached: p95 exceeded X at Y concurrency, or index memory exceeded the largest instance we will operate. Written down in advance, that sentence is worth more than any vendor comparison table, because it also tells you when you were wrong.

• Keep vectors in the same database as tenancy and permissions until measurement says you cannot.
• Build the recall harness before tuning anything. Most “retrieval quality” problems are chunking and metadata problems.
• Write your migration trigger down as a threshold with a number, before you shop.

What to do with the money instead.

Every entry is a real product or a real capability with a link to the vendor’s own page. Where a vendor publishes a price we say so and date it; where they do not, we describe the posture rather than invent a number.

What would change our mind.

If one of these has happened since 2026-08-10, this page is out of date — tell us and we will change it. Pricing and plan contents rot fastest, so check the vendor’s current page before you budget either way.

• A reproducible, non-vendor benchmark showing pgvector failing at the corpus sizes typical of B2B SaaS first features (single-digit millions of chunks) under realistic filtered queries. Filtered recall is where the interesting differences live, and it is the least-benchmarked case.
• A dedicated vector store that makes tenant and permission filtering a first-class transactional concern rather than a metadata-replication exercise. That would remove the strongest argument on this page.
• Your own measurements crossing a threshold you wrote down in advance. That is not us changing our mind — it is the decision rule this page recommends, working as intended.

The questions people ask next.

Is pgvector good enough for production RAG?

For the corpus sizes most B2B SaaS products reach with their first AI features — up to single-digit millions of chunks with filtered queries — yes, and it keeps embeddings transactionally consistent with the documents and permissions they belong to. Prove it with a recall harness and a p95 measurement at your real scale rather than on a vendor's benchmark.

When should we actually move to Pinecone or another dedicated vector database?

When a threshold you wrote down in advance is crossed: p95 latency above your target at production concurrency, index memory or build time beyond the largest instance you are willing to operate, or a retrieval feature (managed hybrid search, reranking, namespace isolation at scale) you cannot reasonably build. Tens of millions of vectors is the neighbourhood where that usually happens.

What does a vector database cost?

Managed vector services are usually usage-based across reads, writes and storage with paid tiers above a free allowance, so the bill tracks traffic rather than seats and is hard to forecast before you have traffic. Read the current pricing page and model your own volumes; pgvector's marginal cost, by contrast, is storage and memory on a database you already pay for.

Written at the Signal Brief desk against the same hard rules the teardown generator follows. pgvector's availability was checked against the extension's own repository and the managed-Postgres providers' extension documentation, and Pinecone's usage-based pricing posture against its own pricing page, all on 10 August 2026. No throughput or recall numbers are quoted here on purpose: published benchmarks in this category are almost always vendor-run, and yours is the only one that decides your architecture.

No sponsorships, no affiliate links and no paid placements anywhere on this site. That is a business-model decision rather than a virtue: a page that names a product and says don’t buy it cannot exist if a vendor is funding it. Corrections to [email protected].

Other calls worth reading.

• LLM observability
  Should we buy an LLM observability platform? Self-host first, then decide
  Do not adopt yet. Instrument with OpenTelemetry, self-host an MIT-licensed collector, and buy a platform when eval workflows — not tracing — become the bottleneck.
• Autonomous coding agent
  Should we buy Devin? Not as a rollout — as a metered two-week experiment
  Do not adopt as a rollout. Buy the smallest metered plan for one named backlog for two weeks, measure merged-without-rework rate, and let that number decide.
• Conversational analytics
  Should we buy ThoughtSpot Spotter? Not before the semantic model exists
  Do not adopt yet. You are being quoted per seat for the interface, while the semantic model that decides whether any answer is correct stays your job.