ScyllaDB adota índice baseado em trie como padrão e triplica throughput

O ScyllaDB é um banco de dados NoSQL de alta concorrência, compatível com APIs do Apache Cassandra e DynamoDB, projetado para cargas intensas em microsserviços, IoT e sistemas de tempo real. Ele usa a biblioteca assíncrona Seastar em C++ para eliminar bloqueios no kernel e maximizar throughput. A mudança para o índice baseado em trie na versão 2026.2 não é só uma otimização de disco: é uma reestruturação da camada de leitura que elimina três estruturas separadas (Summary.db, Index.db, Data.db) por uma única árvore de prefixos persistida em disco, com layout físico cuidadoso para garantir que nós pai e filhos caibam numa mesma página de 4 KB. Isso reduz operações de I/O mesmo em acessos frios, aumenta a densidade no cache de páginas do SO e diminui o uso de largura de banda de armazenamento em até 7×.

A tecnologia foi introduzida como opcional na versão 2025.4 (jan/2026), mas só agora se tornou padrão após validação em clusters produtivos. Diferente de índices B-tree ou Blink-tree (como no PostgreSQL ScyllaDB no GitHub), a trie não depende de balanceamento nem de ponteiros entre nós irmãos, sua eficiência vem da compressão de prefixos compartilhados e da localidade física forçada. Ela serve tanto para índices de partição quanto para índices de clustering key, mas perde vantagem em casos extremos: chaves muito longas com prefixos quase idênticos (ex.: 2048 bytes com diferença só nos últimos 4 bytes) ou workloads com 0% ou 100% de hit no row cache.

Na versão 2025.4, o índice trie era experimental e desativado por padrão, os operadores tinham que habilitá-lo manualmente via configuração. Agora, na 2026.2, ele é o formato padrão para novas SSTables. Não houve mudança na API ou no modelo de dados, mas sim na forma como as leituras são resolvidas sob o capô: o antigo mecanismo de busca binária em Index.db + consulta ao Summary.db foi substituído por navegação direta na trie em disco, com menor profundidade média e melhor aproveitamento de cache de páginas. O artigo-fonte confirma que essa evolução foi impulsionada por maturação técnica, não por pressão de mercado ou rumor.

Para equipes de DevOps e engenharia de plataformas, isso significa menos I/O de disco sob carga, menor pressão sobre storage em nuvem (reduzindo custos operacionais), latência previsível em P99 e maior headroom para escalabilidade vertical sem trocar hardware. Em ambientes onde o ScyllaDB é usado como back-end de serviços com SLA rígido (ex.: notificações push, telemetria de veículos), a queda de 63% na latência de leitura pode evitar timeouts em cadeia. Também simplifica a observabilidade: menos operações de disco facilitam correlação entre métricas de latency, disk reads e CPU usage, algo crítico em pipelines com SLOs definidos por tempo de resposta.