Quando o pgvector começa a ficar lento conforme sua tabela de vetores cresce

Muitos times ativam o pgvector, carregam alguns milhares de linhas de teste, veem resultados rápidos e assumem que será assim para sempre. Na prática, não é. Conforme a tabela cresce, a latência das consultas não se move em linha reta — ela fica estável por um longo tempo e, em um ponto específico, dá um salto brusco. Este guia explica por que isso acontece e como encontrar o seu próprio ponto de ruptura, em vez de copiar benchmarks de terceiros que não refletem o seu hardware, seus dados ou seu padrão de consulta.

O que é o pgvector, na prática

O pgvector é uma extensão do Postgres, não um banco de dados separado. Ele adiciona um tipo de coluna vector a uma tabela normal, permitindo que cada linha guarde seus dados comuns e o embedding lado a lado. Buscar significa perguntar ao Postgres: “encontre as linhas cujos números estão mais próximos desta lista de números”.

Um embedding é uma lista de números que representa o significado de algo — uma frase, uma imagem, uma descrição de produto. Tamanhos comuns são 384, 768 e 1536. Frases com significado parecido geram listas próximas; é isso que torna possível busca semântica, recomendações e RAG (geração aumentada por recuperação).

Os dois índices que mudam tudo

O pgvector oferece duas formas de acelerar a busca:

• IVFFlat: divide os vetores em clusters (“listas”). A busca só verifica alguns clusters em vez de toda a tabela.
• HNSW: constrói um grafo conectando vetores semelhantes. A busca caminha pelo grafo em vez de varrer a tabela.

Sem índice, o pgvector compara cada linha diretamente — é a busca exata por vizinho mais próximo, com 100% de recall. Adicionar um índice muda para busca aproximada: muito mais rápida, mas abrindo mão de parte da precisão. Um detalhe que costuma surpreender: diferente da maioria dos índices de banco, adicionar um índice vetorial aproximado pode mudar os resultados — a mesma consulta pode retornar resultados ligeiramente diferentes entre execuções.

O que causa o salto de latência

Três mecanismos explicam quase tudo:

• HNSW e a memória RAM: o HNSW mantém o grafo inteiro na RAM durante o uso. Enquanto o grafo cabe na memória, a busca fica rápida e previsível. Quando o grafo cresce além da RAM disponível, o Postgres precisa ler partes dele do disco — muito mais lento. Por isso a latência não sobe devagar: ela se mantém até o grafo deixar de caber, e então sobe de uma vez.
• IVFFlat e clusters desbalanceados: embeddings reais raramente se distribuem de forma uniforme. Alguns tópicos são muito mais comuns, sobrecarregando certos clusters. Uma consulta que cai num cluster lotado é lenta; uma que cai num cluster pequeno é rápida. O resultado são picos aleatórios, não uma degradação estável.
• Distância de rede: se a instância do Postgres e a aplicação que a chama não estão próximas, o tempo de rede se soma ao custo do índice. Em pequena escala é invisível; em escala, a distância compõe o problema.

O primeiro a quebrar não é a consulta

Antes de a latência piorar, o que costuma quebrar é o tempo de construção do índice. Construir um índice exige olhar cada vetor e descobrir sua relação com os demais — clusters para IVFFlat, conexões de grafo para HNSW. Esse trabalho cresce com o tamanho da tabela e, no HNSW, com a “minúcia” que você configurar (parâmetros m e ef_construction). Para times que fazem ingestão contínua, esse custo se repete a cada reconstrução e costuma ser notado antes de qualquer mudança de velocidade.

Velocidade ou precisão: escolha um

Velocidade e precisão andam em direções opostas, e o pgvector obriga você a escolher. A pergunta certa não é “o pgvector é rápido o suficiente?”, mas “rápido o suficiente com qual recall, para os meus dados?”. É uma configuração que você ajusta para a própria carga de trabalho — não um número fixo que se transfere da tabela de outra pessoa.

Quando o pgvector faz sentido

O pgvector é uma boa escolha quando você já usa Postgres, quer manter dados e vetores no mesmo lugar e o volume não justifica infraestrutura extra. Um banco vetorial dedicado (Qdrant, Milvus, Pinecone) passa a valer a pena quando a busca vetorial vira o gargalo central, quando o recall aproximado precisa de ajustes finos ou quando a escala supera o que uma instância de Postgres confortavelmente suporta. Nenhuma resposta é universal — depende de onde sua tabela está hoje e para onde ela vai no próximo ano.

Alavancas que adiam o problema

• Precisão reduzida: armazenar vetores em meia precisão ou formato binário encolhe o índice e adia o estouro de RAM, ao custo de algum recall.
• Mais RAM: uma instância com memória suficiente para o grafo HNSW evita o fallback de disco.
• Reconstrução programada: reconstruir índices em janelas de baixo tráfego em vez de continuamente.
• Atualização de versão: versões recentes do Postgres e do pgvector trouxeram melhorias reais de velocidade de build e tamanho de índice.

Como encontrar o seu ponto de ruptura

O teste é direto: gere um conjunto de dados com a mesma dimensionalidade do seu modelo de embedding, construa o índice que pretende usar, rode consultas com recall alvo e aumente o volume progressivamente, observando onde a latência dá o salto. Registre a memória disponível e a distância de rede — são as duas variáveis que mais deslocam a curva.