Pinecone: o vector database padrão pra RAG

Se você está construindo qualquer coisa séria com LLM em 2026, em algum momento esbarra em vector database. E o nome que mais aparece nessa conversa é o Pinecone.

Esse post é um tour direto: o que é, quando vale a pena, como funciona, e onde os concorrentes brilham.

O que é um vector database

Um vector database é otimizado pra guardar embeddings (vetores de alta dimensionalidade, tipo [0.12, -0.45, 0.88, ...]) e responder uma pergunta específica: "quais vetores são mais parecidos com este?"

Não é busca por keyword. É busca por significado. Você pergunta "qual a política de reembolso?" e recebe trechos que falam sobre "devolução em até 30 dias", mesmo sem nenhuma palavra em comum.

A operação central se chama ANN (Approximate Nearest Neighbor) e roda em milissegundos sobre milhões ou bilhões de vetores.

Quando você precisa de um

RAG (Retrieval-Augmented Generation) — buscar trechos relevantes pra injetar no contexto do LLM.
Busca semântica — encontrar documentos parecidos com uma pergunta, não com palavras.
Recomendação — produtos/conteúdos similares a partir de embedding.
Detecção de duplicatas e clustering em escala.

Se o seu caso é "buscar texto exato em um banco pequeno", você não precisa de vector DB. Postgres com ILIKE resolve.

Como funciona, na prática

O fluxo é sempre o mesmo:

Você gera embeddings com algum modelo (OpenAI, Cohere, Voyage, etc.).
Faz upsert no Pinecone com id, values e metadata.
Na hora da query, gera o embedding da pergunta e pede o top-K mais próximo.

import { Pinecone } from "@pinecone-database/pinecone";
 
const pc = new Pinecone({ apiKey: process.env.PINECONE_API_KEY! });
const index = pc.index("docs");
 
await index.upsert([
  {
    id: "post-1",
    values: embedding,
    metadata: { title: "Pinecone", lang: "pt" },
  },
]);
 
const result = await index.query({
  vector: queryEmbedding,
  topK: 5,
  filter: { lang: { $eq: "pt" } },
  includeMetadata: true,
});

Filtros por metadata, namespaces (multi-tenant), hybrid search (denso + esparso) — tudo nativo.

Serverless vs pod-based

Serverless (recomendado hoje) — paga por uso (storage + reads/writes), escala automático, zero infraestrutura. É o default novo.
Pod-based (legado) — você dimensiona pods (s1/p1/p2) por capacidade e latência. Faz sentido em workloads de latência muito previsível e budget grande.

Pra projeto novo: comece serverless. Você só migra se tiver razão concreta.

Trade-offs vs alternativas

Alternativa	Quando faz sentido
pgvector (Postgres)	Você já tem Postgres, volume pequeno/médio, quer SQL + vetor no mesmo lugar.
Qdrant / Weaviate / Milvus	Self-host, open-source, controle total da infra.
Turbopuffer	Custo muito baixo em escala alta, serverless, ótimo pra RAG "frio".
Upstash Vector	Stack Vercel/serverless, baixa fricção, billing simples.
Pinecone	Default seguro, gerenciado, maduro, latência previsível, ecossistema bom.

Onde Pinecone perde: custo em escala. Em volumes grandes (>50M vetores ou alta QPS), Turbopuffer ou pgvector saem bem mais barato. Lock-in é moderado — vetores são portáveis, mas a API é proprietária.

Integração no Vercel

Pinecone está no Vercel Marketplace. Instalável com provisionamento automático de env vars (PINECONE_API_KEY), billing unificado, e plugga direto na AI SDK em rotas de RAG. Pra quem já está na stack Vercel, é o caminho de menor fricção.

Quando não usar Pinecone

Volume pequeno (< 100k vetores) e você já tem Postgres → pgvector.
Self-host obrigatório (compliance, on-prem) → Qdrant.
Escala enorme com budget apertado → Turbopuffer.
Stack 100% Vercel/Upstash com volume modesto → Upstash Vector.

Resumindo

Pinecone é o "default seguro" pra vector DB gerenciado. Não é o mais barato, nem o mais flexível, mas é o que mais raramente dá problema. Pra MVP de RAG, para escala média, e pra time que não quer operar infraestrutura, é uma escolha sólida.

Quando o custo começa a doer ou os requisitos viram exóticos, o mercado tem alternativas reais — e migrar é mais fácil do que parece, porque o ativo de verdade são os embeddings, não a API do banco.