seekdb 2026: trocar 3 bancos por 1 pra IA? Análise real

seekdb é a aposta da equipe por trás do OceanBase de que todo agente de IA vai precisar de um motor de dados único em vez da pilha de três bancos que hoje é padrão de mercado. Toda vez que um agente meu precisa achar “os três tickets mais parecidos com esse, mas só os abertos esse mês”, eu caio na mesma armadilha: busca vetorial num banco, filtro estruturado em outro, e um join feito à mão no código da aplicação, torcendo pra nenhum dos dois lados estar desatualizado. É esse problema específico (não “IA generativa precisa de banco novo”) que o seekdb promete resolver. Vale a pena trocar a stack poliglota por ele? Depende de quanto risco de peça nova você tolera em troca de uma classe inteira de bug a menos.

O problema real que o seekdb ataca

A arquitetura que virou padrão de fato em projeto de RAG ou agente é: um vector store (Pinecone, Qdrant, ou pgvector dentro do próprio Postgres) para embeddings, um RDBMS separado para metadados estruturados (dono do ticket, status, data de criação) e, quando o produto cresce, um Elasticsearch porque busca full-text em vetor ninguém faz direito. Um cenário comum: time roda pgvector pro RAG, mantém o mesmo Postgres (ou um separado) pros metadados estruturados, sobe um Elasticsearch pra busca textual, e aí escreve código de aplicação só pra manter os três sincronizados toda vez que um documento muda. Isso não é falha de engenharia, é consequência de cada peça ser boa numa coisa só.

O README do projeto, no repositório oceanbase/seekdb, resume a proposta como “The AI-Native Search Database” que unifica vetor, texto, dado estruturado e semi-estruturado num motor só, com o slogan “Write. Search. Fork. The State Store for AI Agents.” A ideia não é ser mais um vector DB competindo em velocidade de ANN search isolada. É eliminar o ponto de sincronização entre sistemas, que é onde a maioria dos bugs de produção em agente realmente mora. E geralmente a decisão de unificar ou não a infraestrutura fica adiada até o primeiro incidente de dado dessincronizado entre o índice vetorial e a tabela estruturada, aí vira prioridade de uma hora pra outra.

Dentro do seekdb: herança, novidade e promessa não provada

O que dá (ou tira) credibilidade ao seekdb não é a etiqueta “AI-native”. É de onde ele vem. Segundo o próprio README, o motor é derivado do OceanBase, banco distribuído usado em produção em escala pelo Ant Group, com protocolo compatível com MySQL e engine SQL já testado em ambiente de missão crítica. Isso muda a conversa: não é um projeto que nasceu do zero pra resolver vetor e está improvisando ACID e replicação por cima. É um motor transacional maduro que ganhou camadas novas de busca vetorial e full-text.

O que é genuinamente novo, pelo que a documentação do repositório descreve, é o pipeline assíncrono de indexação (chamado de Change Stream), que separa o commit da escrita da construção do índice HNSW, e o mecanismo de snapshot via copy-on-write, usado para criar “sandboxes” de dados que um agente pode explorar e descartar sem afetar a base principal. Essas duas peças, indexação assíncrona e COW, são código novo escrito especificamente para o caso de uso de agente, e moram em diretórios como src/observer/change_stream/ e src/observer/vector_index/ dentro do próprio repositório.

O que o README promete sem eu poder confirmar de forma independente são os números de desempenho comparando seekdb com Milvus e Elasticsearch, publicados no blog de lançamento do próprio projeto. São benchmarks internos, reproduzíveis (o repositório aponta um projeto separado pra reproduzir o teste), mas ainda assim são números de quem construiu a ferramenta medindo a própria ferramenta. Isso não invalida o resultado, mas também não é a mesma coisa que um benchmark independente de terceiros. Trato esse dado como “a empresa diz que é rápido”, não como fato estabelecido.

A consulta que expõe a diferença

Volto ao cenário do início: “os itens parecidos com esse, mas só os abertos esse mês.” Na stack poliglota isso normalmente vira dois round-trips, um no vector DB pra achar os vizinhos mais próximos, outro no RDBMS pra filtrar por status e data, e você perde atomicidade no meio do caminho. Se o status mudou entre a primeira consulta e a segunda, seu agente decide com base em dado inconsistente, e ninguém percebe até o ticket errado ser escalado pro cliente errado.

No seekdb, segundo os exemplos de SQL do README, essa mesma consulta é uma única instrução:

SELECT id, title, l2_distance(emb, '[0.12,0.34,...]') AS dist
FROM docs
WHERE MATCH(content) AGAINST('quarterly report')
  AND author_id = 42
  AND created_at > '2026-01-01'
ORDER BY dist APPROXIMATE LIMIT 10;

Busca vetorial (l2_distance com APPROXIMATE LIMIT), full-text (MATCH ... AGAINST) e filtro escalar (author_id, created_at) no mesmo plano de execução, sem código de aplicação pra combinar os três resultados. É a diferença entre orquestrar três sistemas na camada da aplicação e empurrar essa orquestração pro otimizador de consultas do banco, que já faz isso há décadas pra join normal, só que agora também pra vetor.

Onde o motor único ganha

A vantagem mais concreta é eliminar uma classe inteira de bug: a dessincronização entre o índice vetorial e a tabela de metadados. Se os dois moram no mesmo motor, sob o mesmo controle transacional ACID (o README afirma “Full ACID, MySQL protocol”), não existe janela de tempo em que um lado já atualizou e o outro não. Isso importa mais pra agente do que pra aplicação tradicional, porque agente toma decisão autônoma com base no que lê. Um dado velho não gera só um relatório errado, gera uma ação errada.

A segunda vantagem é operacional: uma peça a menos pra manter no ar, monitorar, fazer backup e atualizar. Em vez de três sistemas de versão, três dashboards de observabilidade e três pipelines de deploy, é um só. Pra time pequeno de TI isso pesa mais do que parece no papel.

Onde a stack poliglota ainda ganha

Maturidade individual de cada peça é difícil de replicar num produto que, pelos metadados do próprio repositório, é relativamente recente no GitHub. Elasticsearch tem mais de uma década de ajuste fino em produção para full-text em escala; Postgres tem décadas de extensões, ferramentas de migração e DBAs que já resolveram praticamente todo problema clássico de RDBMS. O ecossistema ao redor de cada peça, plugins, observabilidade, consultoria, gente que já bateu a cabeça e escreveu post de troubleshooting, é um ativo que motor novo simplesmente não tem ainda, por mais que a base (OceanBase) seja comprovada.

Unificar motor também concentra risco. Se o seekdb tiver um bug sério de índice vetorial, ele não derruba só sua busca semântica, derruba também seus metadados estruturados, porque é tudo o mesmo processo. Na stack poliglota, uma falha no Elasticsearch não tira o Postgres do ar.

Critério	Stack poliglota (vector DB + RDBMS + search engine)	seekdb (motor único)
Consistência entre vetor e metadado	Responsabilidade da aplicação, risco de dessincronia	Nativa, dentro da mesma transação ACID
Consulta híbrida (vetor + texto + filtro)	Dois ou mais round-trips, merge no código	Uma instrução SQL, um plano de execução
Maturidade de cada componente	Alta, anos de produção em escala	Herdada do OceanBase no motor base; camada de agente é recente
Ecossistema e troubleshooting disponível	Amplo, muita documentação de terceiros	Em formação; apoia-se no ecossistema MySQL
Risco operacional concentrado	Baixo por peça, alto custo de sincronizar	Alto por peça única, baixo custo de manter
Compatibilidade com frameworks de agente	Via integrações específicas de cada banco	Protocolo MySQL + integrações citadas com LangChain, LlamaIndex, Dify

HNSW e copy-on-write: a letra miúda que decide

Dois detalhes técnicos definem se isso aguenta produção ou só demo bonita. O primeiro é o HNSW em dois níveis, um índice incremental (delta) que recebe escritas novas e um índice de snapshot consolidado, junto do pipeline de Change Stream, que consome o redo log de forma assíncrona pra não travar a escrita esperando o índice ser reconstruído. Pelo que a documentação do código-fonte indica, é esse desenho que evita pico de latência sob escrita contínua simultânea com leitura, exatamente o padrão de carga de um agente que grava memória e consulta ao mesmo tempo. Sem ver esse comportamento validado em carga real de produção por terceiros, fico com a descrição da arquitetura (sólida no papel), sem confirmar se ela se sustenta fora do benchmark controlado do próprio time.

O segundo detalhe é o copy-on-write aplicado a nível de kernel do banco, exposto via FORK DATABASE e MERGE TABLE. Isso permite criar um “sandbox” pra um agente explorar, escrever e até quebrar dados, e depois decidir se aceita o resultado de volta (com estratégias de merge tipo FAIL/THEIRS/OURS) ou descarta tudo com DROP DATABASE. É recurso elegante pra agente que precisa testar uma hipótese sem comprometer o estado principal, mas também é a feature mais nova e mais específica do projeto, exatamente a que tem menos tempo de maturação em cenário real.

Minha recomendação: quando trocar e quando não vale o risco

Se você está começando um projeto de agente do zero, com dado que já nasce estruturado e vetorial junto (tickets, documentos, memória de conversa), e o time é pequeno o bastante pra sentir o custo de manter três sistemas sincronizados, vale colocar o seekdb na lista de avaliação, principalmente pelo fato de a base ser o OceanBase, não um projeto experimental sem lastro. A compatibilidade com protocolo MySQL e com LangChain/LlamaIndex citada no README reduz o custo de testar sem reescrever a aplicação inteira.

Se você já tem uma stack poliglota rodando em produção, com Elasticsearch ajustado depois de meses de tuning e Postgres com anos de histórico de queries otimizadas, eu não trocaria agora. O ganho de unificar não paga o custo de migração e o risco de apostar numa camada de agente lançada há pouco tempo, mesmo que o motor por baixo seja confiável. Dá pra adiar essa decisão sem culpa até ver mais relatos de uso em carga real, não só benchmark do próprio fabricante.

Minha visão geral é que “banco especializado sempre vence generalista” é crença que só é verdadeira olhando uma dimensão de cada vez (latência de busca vetorial isolada, por exemplo). Na prática de produção, a dimensão que mais dói não é performance de componente, é sincronização entre componentes. O seekdb ataca exatamente essa dor, e isso o torna relevante mesmo sem ser o mais rápido em cada categoria isolada. “Relevante” não é o mesmo que “pronto pra apostar sua base de produção hoje”. Eu acompanharia de perto, testaria em projeto novo e de baixo risco, e deixaria a migração de sistema legado pra quando o histórico de produção for maior do que alguns meses de GitHub.

Fontes consultadas

• Repositório oficial: github.com/oceanbase/seekdb, README, metadados do projeto (linguagem, licença Apache-2.0, tópicos) e exemplos de código SQL.
• Site do projeto: seekdb.ai (citado no README como documentação oficial).
• Blog de lançamento do projeto, referenciado dentro do próprio README (docs/blog/launch_blog_en.md), para os números de benchmark, tratados aqui como fonte do próprio fabricante, não validação independente.