← Voltar ao blog
MariaDB 28 de outubro de 2026 10 min de leitura

TidesDB no MariaDB: o que é, quando usar e como instalar

O TidesDB chegou ao MariaDB como storage engine LSM. Veja para que serve, quando usar e quando evitar, exemplos em fintechs, seguros e varejo, e como instalar e testar.

TidesDB no MariaDB: o que é, quando usar e como instalar

Em uma frase: o TidesDB virou um storage engine plugável do MariaDB. Com ele, suas tabelas podem gravar dados com uma arquitetura LSM, pensada para escrita pesada, CPUs com muitos núcleos e discos NVMe, enquanto você continua usando o SQL de sempre. Vou explicar do jeito que eu gostaria que tivessem me explicado: o que é, para que serve, quando usar, quando não usar e, por fim, como instalar e brincar com ele na prática.

Primeiro: o que é um storage engine?

O MariaDB separa o "cérebro" (parser SQL, otimizador, permissões, replicação) do "músculo" que grava e lê os bytes no disco. Esse músculo é o storage engine. O padrão é o InnoDB, mas você pode escolher outro por tabela: ColumnStore para análises, Aria, Spider para sharding e por aí vai. Se esse assunto é novo para você, comece pelo nosso guia storage engines do MariaDB explicados.

O TidesDB é um motor chave-valor transacional, open source e escrito em C. Ele não é um servidor: não tem porta, login nem SQL próprio. Foi feito para ser embutido em outros sistemas, e o plugin TideSQL o encaixa dentro do MariaDB. Você ganha o motor do TidesDB por baixo e o MariaDB inteiro por cima.

Como ele funciona, sem dor de cabeça

  • LSM em vez de B-tree: o InnoDB atualiza páginas "no lugar", como quem corrige uma ficha num arquivo. O TidesDB anota tudo no fim de um caderno (escrita sequencial) e organiza depois, em segundo plano. É a compactação. Escrever no fim do caderno é muito barato.
  • Chave separada do valor: as chaves ficam na estrutura ordenada e os valores num log sequencial. Isso reduz a amplificação de escrita, ou seja, quantas vezes o mesmo dado é regravado no disco. É bom para o bolso e para a vida útil do SSD.
  • Sem travas (lock-free): as estruturas internas foram desenhadas para muitos núcleos trabalhando ao mesmo tempo.
  • MVCC otimista: leitor não bloqueia escritor e vice-versa. Conflitos são resolvidos na hora do commit.

Quando usar

A regra de bolso: muita escrita, chegando sem parar, e o dado novo vale mais que o antigo. Alguns cenários típicos por setor (são exemplos de padrão de carga, não casos publicados de empresas):

  • Fintechs: trilha de auditoria, eventos de transação, logs de antifraude e rastreamento de Pix, ou seja, milhões de inserções que quase nunca são alteradas.
  • Seguradoras: telemetria de seguro auto por uso (o quanto e como você dirige), dados de sensores de IoT residencial e histórico de cotações.
  • Varejo e e-commerce: clickstream (cada clique do cliente), eventos de carrinho, histórico de preços e movimentação de estoque em tempo real.
  • Healthtechs: leituras contínuas de dispositivos de monitoramento e logs de acesso a prontuário exigidos pela LGPD.
  • Telecom, logística e indústria: CDRs (registros de chamadas), rastreamento de frota por GPS e séries temporais de máquinas.
  • SaaS em geral: filas de eventos, logs de aplicação, métricas e qualquer tabela "append-only".

Quando NÃO usar

  • Quando você ainda não testou. É um motor recém-chegado ao ecossistema. Seu ERP em produção não é o laboratório.
  • Muita atualização no mesmo registro (saldo de conta alterado a cada segundo, por exemplo): o LSM guarda versões e a compactação precisa limpar depois.
  • Relatórios analíticos pesados varrendo bilhões de linhas: aí o caminho é o ColumnStore.
  • Quando você depende de recursos específicos do InnoDB (chaves estrangeiras, ferramentas de backup, tuning que a equipe já domina). Valide cada um antes de trocar.
  • Disco lento: o design brilha em NVMe. Em disco mecânico, o ganho tende a encolher.

Quão rápido é?

Vou ser honesto, que é o que vale aqui: o artigo da MariaDB Foundation que usei como referência não publica números. A proposta dele é dar o mapa para qualquer um rodar os benchmarks de forma reproduzível com o TAF, o framework de testes de desempenho da Foundation. Os cenários preparados medem leitura (POINT_SELECT, OLTP_RO) e escrita (OLTP_RW, OLTP_WO) em duas máquinas cedidas pela Hetzner: um Intel i5-13500 de 20 threads e um AMD EPYC 9454 com 96 threads.

Pela arquitetura, a expectativa é ganho principalmente em escrita intensa e alta concorrência, com leitura pontual competitiva. Mas expectativa não é medição. Meça com a sua carga. Já já te mostro como.

Por que usar o TidesDB dentro do MariaDB?

  • Você não abandona o SQL: JOINs, views, procedures, usuários, permissões e conectores continuam iguais.
  • Escolha por tabela: a tabela de eventos vai para o TidesDB e o cadastro de clientes continua no InnoDB, no mesmo banco.
  • Um só ecossistema para operar: monitoramento, ferramentas e equipe que já conhecem MariaDB.
  • Open source de ponta a ponta, com testes reproduzíveis publicados pela própria Foundation.

Na prática: instalando

Segundo a Foundation, o TidesDB vem empacotado com o MariaDB 11.4.13 (RHEL 9 / AlmaLinux 9 / Rocky 9) no espelho oficial. Os pacotes são: server, client, common, devel, shared e o MariaDB-plugin-tidesdb.

# Opção 1: instalar direto, num servidor de testes
sudo dnf install ./MariaDB-server-11.4.13-1.el9.x86_64.rpm \
  ./MariaDB-client-11.4.13-1.el9.x86_64.rpm \
  ./MariaDB-common-11.4.13-1.el9.x86_64.rpm \
  ./MariaDB-shared-11.4.13-1.el9.x86_64.rpm \
  ./MariaDB-plugin-tidesdb-11.4.13_5.0.0-1.el9.x86_64.rpm
sudo systemctl start mariadb

Depois, carregue o plugin e confira. O nome exato da biblioteca pode variar conforme o pacote. Liste com rpm -ql MariaDB-plugin-tidesdb se der erro:

INSTALL SONAME 'ha_tidesdb';
SHOW ENGINES;          -- procure TIDESDB na lista
SHOW PLUGINS;

Atenção: trocar o motor não é só escrever ENGINE=TIDESDB. O plugin precisa estar instalado, com diretório de dados (tidesdb_data_home_dir) e diretório de plugins configurados corretamente.

Na prática: usando

CREATE DATABASE lab_tides;
USE lab_tides;

-- Tabela de eventos de pagamento: muita escrita, pouca alteração
CREATE TABLE eventos_pagamento (
  id          BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  conta_id    BIGINT UNSIGNED NOT NULL,
  tipo        VARCHAR(20) NOT NULL,     -- 'pix_in', 'pix_out', 'estorno'
  valor       DECIMAL(14,2) NOT NULL,
  criado_em   DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
  PRIMARY KEY (id),
  KEY idx_conta_data (conta_id, criado_em)
) ENGINE=TIDESDB;

INSERT INTO eventos_pagamento (conta_id, tipo, valor)
VALUES (42, 'pix_in', 150.00), (42, 'pix_out', 37.90), (7, 'pix_in', 1000.00);

-- Leitura pontual e por faixa, como sempre
SELECT * FROM eventos_pagamento
WHERE conta_id = 42 AND criado_em >= NOW() - INTERVAL 1 DAY;

-- Convertendo uma tabela existente (em homologação!)
ALTER TABLE logs_app ENGINE=TIDESDB;

Na prática: medindo com o TAF

Para comparar com o InnoDB de forma séria, use o mesmo roteiro da Foundation:

git clone https://github.com/MariaDB/TAF.git
cd TAF/taf-perl

# Instala MariaDB + plugin a partir dos RPMs (ajuste os caminhos)
perl taf.pl --verbose --db-software-install \
  --db-software-install-packages=/rpms/MariaDB-server-11.4.13-1.el9.x86_64.rpm,/rpms/MariaDB-plugin-tidesdb-11.4.13_5.0.0-1.el9.x86_64.rpm,...

# Compila o sysbench contra essa instalação
perl taf.pl --properties=properties/mariadb/tidesdb/sysbench_tidesdb_small_host_writes.properties \
  --action=build-client

# Ajuste PROP_DIR e INSTALL_DIR no script e rode
./scripts/mariadb/tidesdb/tidesdb_small.sh

Dica de quem já apanhou: os caminhos nos .properties (tidesdb_data_home_dir, taf.db_plugin_dir) e nos scripts (PROP_DIR, INSTALL_DIR) precisam ser ajustados ao seu ambiente. É aí que 90% das tentativas quebram.

Meu veredito

O TidesDB é aquela ferramenta que não substitui o InnoDB, mas complementa. Para tabelas de eventos, logs e telemetria, vale um teste sério já. Para o núcleo transacional, vale acompanhar de perto, medir e esperar a maturidade. E o mais legal é ver o MariaDB continuar plugável e aberto a inovação. Quer outras ideias de motores? Volte ao hub MariaDB.

Créditos e agradecimento

Este artigo é uma explicação em português inspirada no excelente post de Jonathan "Jeb" Miller no blog da MariaDB Foundation. Obrigado, Jeb, pelo roteiro claro e reproduzível. Parabéns também a Alex (Gaetano) Padula, criador do TidesDB, pelos anos de trabalho que trouxeram esse motor para o MariaDB, e à Hetzner, que cedeu o hardware dos testes.

Leia o original (em inglês): MariaDB Foundation: Exploring TidesDB Performance with TAF.