---
title: "Decision: Supabase pgvector over Pinecone"
url: https://memory.wiki/frK9IDOy
updated: 2026-05-14T18:15:49.480Z
hub: https://memory.wiki/hub/demo
concept_count: 12
source: "memory.wiki"
---
# Decision: Supabase pgvector over Pinecone

> Logged 2026-03-08 after a 2-day evaluation. Status: locked.

## What we picked

`pgvector` + HNSW inside the existing Supabase Postgres instance. **Not** Pinecone, Weaviate, Chroma, or Turbopuffer.

## What we measured

I built two prototypes against the same 4,200-document corpus (my actual hub plus a synthetic test set):

| Backend | Build time | Read p99 | Cold-start p99 | $/month at our scale |
|---|---:|---:|---:|---:|
| pgvector + HNSW | 41s | 18ms | 22ms | $0 (incl. with Postgres) |
| Pinecone serverless | n/a | 11ms | 380ms | ~$32 |

The cold-start gap was the surprise. Pinecone serverless can spike past 300ms when an index hasn't been touched in a few minutes, which is exactly our access pattern (bursty, per-user). pgvector inside the warm Postgres pool is steady.

## The argument for choosing the cheaper, slower-at-the-best-case option

- **One vendor, one auth surface, one migration story.** Adding Pinecone means a second SDK, a second control plane, a second set of API keys to rotate, a second "what region does it run in" answer.
- **18ms p99 read is well inside our 100ms recall budget.** The reranker is the bottleneck, not the vector store.
- **Postgres lets us join.** Filter by `user_id`, `folder_id`, `is_draft = false`, and `created_at > $cutoff` in the same query that returns the cosine match. Pinecone metadata filtering exists but is its own DSL.

## Where this stops being the right call

At ~50K vectors per user, HNSW recall starts to degrade unless we tune `ef_search`. We're nowhere near that. When we cross 30K we revisit, but we project that as the H2 2027 problem — not this quarter's.

## What I won't reconsider

The "but Pinecone is the obvious vector DB" pressure. It's the obvious choice in slide decks. The numbers say otherwise for our specific shape.


---

## Concepts in this document
- **Supabase** _(entity)_
  Backend-as-a-service providing authentication, database, and row-level security without separate auth overhead.
- **Vendor consolidation** _(concept)_
  The operational principle of reducing authentication surfaces, SDKs, and control planes by keeping vector search within the existing Postgres infrastructure.
- **pgvector** _(entity)_
  PostgreSQL extension providing vector data type and HNSW indexing for efficient similarity search.
- **Anthropic** _(entity)_
  Incumbent AI vendor mentioned as competitive threat with integrated memory and user lock-in.
- **Performance Optimization** _(concept)_
  Critical performance considerations driving technical architecture decisions.
- **AI-First Architecture** _(concept)_
  Design philosophy that assumes AI capabilities replace traditional manual processes.
- **Supabase Postgres** _(entity)_
  The existing database infrastructure that pgvector extends, serving as the single unified platform for relational and vector queries.
- **comrak** _(entity)_
  The Rust markdown parser selected for production use due to GFM compliance and performance.
- **Cost Optimization** _(tag)_
  Financial considerations in technology and vendor selection decisions.
- **Rust + WASM** _(entity)_
  Core technology stack providing performance advantages for markdown rendering.
- **Anthropic Haiku 4.5** _(entity)_
  The selected reranker model chosen to rerank hybrid retrieval results in the hub-recall pipeline.
- **AI-First Design** _(concept)_
  Product philosophy prioritizing AI agent compatibility over traditional user patterns.

## Concept relations (within this doc's concepts)
- **AI-First Architecture** synergizes with **Vendor consolidation**
- **Performance Optimization** balanced priorities **Cost Optimization**
- **Vendor consolidation** reduces complexity costs **Cost Optimization**
- **Anthropic** supports strategy **Vendor consolidation**
- **Supabase** enables approach **Vendor consolidation**
- **Supabase** hosts **pgvector**
- **Supabase** exemplifies approach **Vendor consolidation**
- **Supabase** reduces complexity **Vendor consolidation**
- **Supabase** integrates **pgvector**
- **Supabase** exemplifies strategy **Vendor consolidation**
- **Vendor consolidation** guides **Supabase**

_Hub canonical:_ https://memory.wiki/hub/demo
_Concept digest:_ https://memory.wiki/raw/hub/demo?digest=1&compact=1