Cortex Otimiza Busca com PostgreSQL Full-Text, Reduzindo Latência e Memória

A Cortex implementou uma mudança estratégica em sua arquitetura de busca, trocando uma solução baseada em Lucene por uma abordagem integrada ao PostgreSQL full-text search. O movimento não foi trivial e veio para resolver desafios críticos de escalabilidade. A antiga infraestrutura Lucene sofria com exceções de falta de memória (OOM), latência de cauda longa para consultas

A abordagem da Cortex representa uma escolha estratégica por simplicidade e compatibilidade. A empresa optou por uma solução de busca full-text no PostgreSQL utilizando recursos nativos e extensões padrão, como o unaccent, que são amplamente compatíveis com serviços gerenciados em nuvem. Essa decisão contrasta com o uso de extensões de alto desempenho como a TIN, que o CEVIU News cobriu em 21 de setembro de 2026, que oferecem funcionalidades avançadas mas podem ter maior carga operacional ou restrições de implantação.

O sistema anterior baseado em Lucene, com construção de índices por cron, tinha latência de p95 de 13,3 segundos. Com a nova arquitetura baseada em PostgreSQL, a latência caiu drasticamente para 1,54 segundos. Além disso, o consumo de memória foi reduzido em aproximadamente 40%, e a “freshness” dos dados melhorou de minutos para segundos, com a maioria das edições sendo indexadas e pesquisáveis quase instantaneamente.

A transição da Cortex demonstra a versatilidade e a maturidade do PostgreSQL como uma plataforma capaz de lidar com cargas de trabalho complexas como busca full-text em larga escala, muitas vezes associadas a soluções de busca externas mais complexas. A estratégia de usar Change Data Capture (CDC) para atualizações em tempo real e um parser customizado diretamente no banco de dados reflete uma tendência de otimização de performance e custo operacional, priorizando o aproveitamento máximo da infraestrutura existente.

Para desenvolvedores, este caso de sucesso mostra que é possível construir funcionalidades de busca robustas e eficientes com menos complexidade na stack e maior previsibilidade de desempenho, aproveitando a familiaridade e a estabilidade de um banco de dados relacional. Reforça a importância de avaliar as necessidades do projeto e as restrições do ambiente ao escolher entre