Pinecone: o que é e como usar

Nossa participação é quase nula e vale declarar mesmo assim: somos a Geonode e vendemos proxies, que não têm nada a ver com bancos de dados vetoriais. A única adjacência é que um sistema de recuperação precisa de algo sobre o que recuperar, e se esse conteúdo vem da web pública, alguém tem de coletá-lo — que é a nossa ponta do pipeline e é inteiramente separada do banco. Nada neste artigo exige comprar nada de nós, e a seção que argumenta contra um banco vetorial gerenciado está incluída porque frequentemente é a resposta certa.

O que um banco vetorial faz

Bancos de dados comuns fazem correspondência exata. Um banco vetorial corresponde por similaridade.

O mecanismo: um modelo de embedding converte texto, imagens ou outro conteúdo em uma lista de números — um vetor — posicionado de modo que coisas semelhantes fiquem próximas. Encontrar resultados relevantes vira encontrar pontos próximos, um problema de geometria em vez de correspondência de strings.

O Pinecone se descreve como "the vector database for AI agents and applications, built for semantic search, knowledge retrieval, and long-term memory at scale", com a capacidade apresentada como buscar "through billions of items for similar matches to any object, in milliseconds".

O motivo de isso ter virado infraestrutura em vez de biblioteca é a escala. Comparar uma consulta com um milhão de vetores por força bruta é direto e lento; fazer isso em milissegundos exige indexes de vizinho mais próximo aproximado, e operá-los de forma confiável em escala é um problema de operações. É isso que um serviço gerenciado vende.

O caso de uso dominante é a geração aumentada por recuperação: dada a pergunta de um usuário, encontrar as passagens mais relevantes dos seus próprios documentos e entregá-las a um modelo de linguagem como contexto. O banco fornece a etapa de "encontrar as passagens relevantes".

Indexes, documentos e records

O modelo de dados do Pinecone mudou de forma e vale entender como está hoje.

Um index é onde os dados vivem. A documentação explica que "a serverless index holds your data as documents or records, depending on how the index was created: an index created with a document schema holds documents, while an index created with a dense or sparse vector type holds records".

Um schema de documento permite que um único index faça vários trabalhos. Segundo a documentação, "a single index with a document schema can mix multiple ranking field types: a dense_vector field for semantic search, a sparse_vector field for sparse-vector retrieval, and one or more string fields with full_text_search enabled for full-text search with BM25 and Lucene queries."

Metadados não precisam de declaração. "Any other fields you upsert are stored as metadata, automatically indexed for filtering — no schema declaration required."

A orientação de desenho é clara: "One index per use case is the typical pattern. Because a document can combine vectors, text, and metadata in the same record, a single index often covers what previously required two — pick the ranking signal per query with score_by."

Esse último ponto é o significativo. A busca full-text fica disponível junto da busca vetorial no mesmo index — "BM25 token matching with Lucene query syntax over text fields in your schema", com o Pinecone cuidando de "tokenization, IDF, and length normalization at index time and BM25 scoring at query time". Sem motor de busca separado, e sem modelo para a metade de palavras-chave.

A consequência prática é que a busca híbrida — combinar similaridade semântica com correspondência exata de palavras-chave — é uma escolha em tempo de consulta, não de arquitetura. Isso importa, porque a busca puramente vetorial é notoriamente fraca em identificadores exatos, códigos de produto e nomes próprios raros, e o BM25 é excelente exatamente nisso.

Namespaces

O recurso que mais afeta como você desenha um aplicativo multi-tenant.

A documentação: "Within an index, records are partitioned into namespaces, and all upserts, queries, and other data read and write operations always target one namespace."

Dois benefícios são nomeados. Multitenancy — "when you need to isolate data between customers, you can use one namespace per customer and target each customer's writes and queries to their dedicated namespace." E consultas mais rápidas — "when you divide records into namespaces in a logical way, you speed up queries by ensuring only relevant records are scanned."

Três notas operacionais.

Eles são criados implicitamente. "Namespaces are created automatically during upsert. If a namespace doesn't exist, it is created implicitly." Conveniente, e isso significa que um erro de digitação no nome de um namespace produz uma busca silenciosamente vazia em vez de um erro.

O limite depende do plano. "Namespaces per serverless index vary by plan. On the Standard and Enterprise plans, Pinecone can accommodate million-scale namespaces and beyond for specific use cases. If your application requires more than 100,000 namespaces, contact Support."

O isolamento é o ponto. Para qualquer coisa que guarda dados de vários clientes, um namespace por cliente é o padrão, e isso torna o vazamento entre tenants uma questão de acertar um parâmetro, não de acertar um filtro.

Embeddings: os seus ou os deles

Duas abordagens, e a escolha tem consequências reais.

Embedding integrado. A documentação descreve em quatro passos: "Create an index that is integrated with one of Pinecone's hosted embedding models. Upsert your source text. Pinecone uses the integrated model to convert the text to vectors automatically. Search with a query text. Again, Pinecone uses the integrated model to convert the text to a vector automatically."

Mais simples — você envia texto e recebe resultados, sem um pipeline de embedding próprio. Uma restrição documentada: "Indexes with integrated embedding do not support updating or importing with text."

Traga seus próprios vetores. Você executa o modelo de embedding, cria um index que combine com suas características e faz upsert dos vetores diretamente, usando "the same external embedding model to convert a query to a vector".

Mais trabalho, e mais controle. Permite usar um modelo que o Pinecone não hospeda, rodar o embedding localmente por privacidade ou custo e — crucialmente — trocar de modelo no seu próprio ritmo.

A consideração que decide para muita gente: trocar o modelo de embedding significa re-embeder tudo. Vetores de modelos diferentes não são comparáveis, então a troca é um reindex completo. O embedding integrado facilita a construção inicial e amarra a decisão ao catálogo de modelos do fornecedor; trazer os seus torna a construção mais difícil e mantém a escolha sua. Nenhum dos dois está errado, e vale decidir de propósito em vez de seguir o primeiro tutorial que você encontrou.

Carregar dados em escala

Uma nota de custo fácil de passar e cara de descobrir.

A documentação é específica: "To control costs when ingesting large datasets (10,000,000+ records), use import instead of upsert."

Existem duas rotas de ingestão. Upsert envia records pela API. Import lê arquivos Parquet do object storage, e a documentação chama isso de "the most efficient and cost-effective way to load large numbers of records into an index".

Como as escritas são cobradas por milhão de write units, a diferença entre esses dois caminhos em uma carga inicial grande é um número real, não um erro de arredondamento. Se você está montando um index sobre milhões de records, planeje o caminho de import desde o início — adaptar depois de uma primeira carga cara é uma lição que ninguém precisa pagar duas vezes.

Começando na prática

A forma de uma primeira implementação, e as decisões embutidas nela.

Crie um index e faça upsert. Com embedding integrado o fluxo é curto — você nunca toca em um vetor:

from pinecone import Pinecone

pc = Pinecone(api_key=API_KEY)

index = pc.Index(host=INDEX_HOST)

index.upsert_records(
    namespace="customer-42",
    records=[
        {"_id": "doc-1", "chunk_text": "Refunds are processed within 14 days.",
         "source": "policy.pdf", "page": 3},
        {"_id": "doc-2", "chunk_text": "Shipping to the EU takes 3-5 working days.",
         "source": "shipping.pdf", "page": 1},
    ],
)

Note que source e page nunca foram declarados. Qualquer coisa além dos campos de ranking é armazenada como metadado e indexada para filtro automaticamente, o que significa que você pode adicionar campos depois sem uma migração.

Consultar com um filtro:

results = index.search(
    namespace="customer-42",
    query={"inputs": {"text": "how long do refunds take?"}, "top_k": 5,
           "filter": {"source": {"$eq": "policy.pdf"}}},
)

Três decisões nesse trecho valem ser tomadas de propósito.

Tamanho do chunk. O texto que você envia no upsert é a unidade que volta, então o chunking determina o que seu modelo vê. Chunks pequenos demais perdem o contexto que os torna significativos; grandes demais e você recupera texto irrelevante junto da frase relevante. Não há resposta universal — algumas centenas de palavras com alguma sobreposição é um ponto de partida razoável, e medir ganha de adivinhar.

Metadados são sua superfície de filtro. Guarde qualquer coisa pela qual você possa querer restringir depois: documento de origem, data, seção, idioma, nível de acesso. Adicionar no momento do upsert não custa nada; adicionar depois significa reenviar tudo.

Namespace por tenant, sempre, desde o começo. Encaixar isolamento depois em um index de um único namespace significa reenviar tudo com o alvo certo. Começar com namespaces custa um parâmetro e remove uma categoria inteira de incidente futuro.

E conserve o texto-fonte. Guarde os documentos originais em algum lugar que você controla, junto do código de chunking. Se você mudar o modelo de embedding, o tamanho do chunk ou a estratégia de chunking — e vai mudar — reconstruir o index vira uma reexecução, não um exercício de arqueologia.

Preços, verificados

Da própria página de preços do Pinecone, conferida em setembro de 2026. Verifique antes de orçar.

Quatro observações que importam para o planejamento.

O plano gratuito é de fato usável para avaliação. Dois gigabytes de armazenamento e um milhão de read units mensais bastam para montar um protótipo real sobre um conjunto substancial de documentos.

Builder é taxa fixa, não mínimo. A US$ 20/mês com tetos fixos, é previsível de um jeito que os planos baseados em uso não são — útil para um aplicativo de produção pequeno em que você prefere uma fatura que dá para prever.

Standard e Enterprise são mínimos com excedente. Os US$ 50 e US$ 500 são pisos, não tetos. Seu custo real é baseado em uso acima deles.

Leituras custam cerca de quatro vezes as escritas por milhão de units. A US$ 16–US$ 18 por milhão de read units contra US$ 4–US$ 4,50 nas escritas, um aplicativo pesado em leitura — que a maioria dos sistemas de recuperação é — vai ver as consultas dominarem a fatura. Cachear consultas frequentes é, portanto, uma alavanca direta de custo, não só de latência.

O Enterprise acrescenta SLA de 99,95% de uptime, implantação bring-your-own-cloud, private endpoints e logs de auditoria — o conjunto usual de coisas que importam para um processo de compras e nada para um protótipo.

Quando você não precisa de um banco vetorial gerenciado

A seção que um fornecedor não escreveria, incluída porque frequentemente é a resposta.

Quando seu corpus é pequeno. Abaixo de cerca de cem mil vetores, a busca de similaridade por força bruta em memória é rápida o bastante em hardware comum. Um array NumPy e um produto escalar respondem em milissegundos, não custam nada e removem uma dependência externa da sua arquitetura. O limiar em que a indexação aproximada se torna necessária é mais alto do que a maioria das pessoas assume.

Quando você já roda Postgres. A extensão pgvector adiciona busca por similaridade vetorial a um banco que você já opera e já faz backup. Para muitos aplicativos essa é a resposta correta: um sistema a menos, consistência transacional com seus outros dados, e nenhuma fatura separada.

Quando uma biblioteca embarcada basta. Bibliotecas como FAISS ou um vector store local lidam com milhões de vetores em um único processo. Se seus dados cabem em uma máquina e o volume de consultas é modesto, um serviço gerenciado está resolvendo um problema de operações que você não tem.

Quando a busca por palavra-chave funcionaria. Uma parcela significativa de "precisamos de busca semântica" acaba bem atendida pelo BM25, que é mais barato, mais rápido, inteiramente explicável e melhor em identificadores exatos. Experimente primeiro — e note que, se você acabar no Pinecone, a busca full-text dele cobre isso no mesmo index.

Quando você ainda não mediu a qualidade da recuperação. O banco normalmente não é o fator limitante em um sistema de recuperação. Estratégia de chunking, escolha do modelo de embedding e formulação da consulta importam muito mais, e as três podem ser testadas com cem linhas de código local antes de qualquer decisão de infraestrutura.

O caso a favor de um serviço gerenciado é real e específico: muitos milhões de vetores, volume de consultas que exige baixa latência consistente, isolamento multi-tenant, e um time que prefere não operar um index distribuído. Se dois ou mais desses se aplicam, ele paga o custo.

Perguntas frequentes

Para que o Pinecone é usado?

Busca semântica, recuperação de conhecimento e memória de longo prazo para aplicativos de IA. O padrão dominante é a geração aumentada por recuperação: encontrar as passagens dos seus próprios documentos mais relevantes para uma pergunta e fornecê-las a um modelo de linguagem como contexto.

O Pinecone é gratuito?

Há um plano Starter gratuito com até 2 GB de armazenamento, 2M de write units e 1M de read units por mês, e 1 GB de egress. É de fato o bastante para construir e avaliar um protótipo real antes de se comprometer com um plano pago.

Quanto custa o Pinecone?

Starter é gratuito; Builder é US$ 20/mês fixos com tetos fixos; Standard tem mínimo de uso de US$ 50/mês e Enterprise US$ 500/mês, ambos cobrando armazenamento a US$ 0,33/GB/mês, escritas a US$ 4–US$ 4,50 por milhão de units e leituras a US$ 16–US$ 18 por milhão, com egress a US$ 0,10/GB depois de 100 GB.

O que é um namespace no Pinecone?

Uma partição dentro de um index. Toda leitura e escrita mira exatamente um namespace, o que o torna o mecanismo padrão de isolamento multi-tenant — um namespace por cliente — e uma otimização de desempenho, já que as consultas varrem só a partição relevante.

Devo usar embedding integrado ou meus próprios vetores?

O embedding integrado é mais simples: envie texto, o Pinecone converte. Trazer os seus dá escolha de modelo e portabilidade, o que importa porque trocar o modelo de embedding exige re-embeder tudo. Indexes integrados também não suportam update nem import com texto.

O Pinecone faz busca por palavra-chave além da busca vetorial?

Sim. Campos string com full_text_search habilitado suportam ranking BM25 com sintaxe de consulta Lucene, no mesmo index que vetores densos e esparsos, com o método de pontuação escolhido por consulta. Isso importa porque a busca puramente vetorial lida mal com identificadores exatos e termos raros.

Como carrego milhões de records com eficiência?

Use import a partir de object storage em vez de upsert. A documentação recomenda isso explicitamente para conjuntos acima de dez milhões de records e descreve como a rota mais econômica, o que importa dado que as escritas são cobradas por milhão de units.

Preciso mesmo de um banco vetorial?

Muitas vezes não. Abaixo de cerca de cem mil vetores, força bruta em memória é rápida o bastante e gratuita. Se você já roda Postgres, o pgvector evita um sistema separado. E uma parcela justa dos requisitos de "busca semântica" é bem atendida por busca por palavra-chave, que é mais barata e mais explicável.

Conclusão

O Pinecone é um banco de dados vetorial gerenciado que cresceu para algo mais amplo: um único index agora pode guardar vetores densos, vetores esparsos e campos full-text juntos, com o método de ranking escolhido por consulta. Essa consolidação é a mudança recente mais útil, porque a recuperação híbrida deixa de ser uma decisão de arquitetura e vira um parâmetro.

Três coisas moldam como você deve projetar em cima disso. Namespaces são o mecanismo de isolamento e desempenho, e são criados implicitamente — então um namespace digitado errado devolve um resultado vazio em vez de um erro. A escolha de embedding é mais aderente do que parece, já que trocar de modelo significa re-embeder o corpus inteiro. E as leituras custam várias vezes o que as escritas custam, o que torna o cache de consultas uma alavanca direta de custo em um sistema pesado em leitura.

Os preços são transparentes e o plano gratuito é grande o bastante para responder à pergunta real, que é se a qualidade da recuperação é boa o bastante para o seu caso. Essa pergunta não é sobre o banco — chunking, escolha de embedding e formulação da consulta a dominam — e pode ser respondida localmente antes de qualquer infraestrutura existir.

Esse é o ponto de fechamento honesto. Um banco vetorial gerenciado ganha seu lugar em escala, com multi-tenancy, ou quando você prefere não operar um index distribuído. Abaixo disso, um array em memória ou uma extensão no Postgres que você já roda fará o trabalho de graça, e vale estabelecer em qual situação você está antes de assinar qualquer um dos dois.