Como o SQLite (e Turso cloud) Revolucionam a Arquitetura Multitenant

Eu mexo com programação desde o ano 2000. Aprendi Lógica de programação em Pascal e depois Java. Era uma época bem diferente da atual, fiz um curso presencial de Java, na sua versão 1.3. Aliás, usávamos o jdk 1.3, mas a versão que aprendíamos era anterior. Lembro carinhosamente do nosso amigo e professor "Chopão", na Digitech em Palmas/TO.

Naquela época, como os materiais não eram tão acessíveis, eu digitava o código que aprendia e, ao compilar, já via no console: deprecated, deprecated. Como qualquer outro curso da época e, mesmo atualmente ainda acontece, embora em menor escala.

Mas há coisas que se depreciam ou, mesmo parecendo atuais, estão depreciadas ou claramente erradas. Eu gostaria de falar sobre uma coisa especificamente: SQLite não é para produção.

Embora tenha parado de programar e voltado várias vezes, voltei para ficar há cerca de quatro anos atrás. Iniciei estudando django que já usava o sqlite por padrão. Com o tempo, verifiquei na documentração que não era recomendado usar SQLite para produção. Pesquisando, eu vi no site do SQLite que ele aguenta muita coisa, mas havia receio. Naquela época, coloquei um sistema para rodar em produção (ainda rodando hoje) em SQLite. Nesse meio tempo, vi uma palestra no DjangoCon sobre usar SQLite em produção que, é mais do que a maioria avassaladora dos sites precisa e, se ativaro modo WAL (Write-ahead logging) ele fica ainda mais (e muito mais) performático.

As pessoas acreditavam tanto em SQLite que apareceram tecnologias como Litestream para facilitar backups e replicação.

Se pensarmos em arquitetura multitenant, há várias abordagens. Em apertada síntese, uma delas é usar um DB somente e uma coluna discriminadora. É simples e tranquila, mas há riscos envolvendo a falta de isolamento de dados (imagine você mostrando dados pessoais sensíveis no sistema de um cliente, mas os dados estão sendo legalmente processados por outro cliente do seu multitenant?). Além disso, um dos "locadores" podem usar muitos recursos, prejidicando todos os outros. A segunda abordagem é a por esquema (na concepção do Postgres, poq no mysql um esquema é um DB até onde eu sei). Isola bem melhor os dados, mas ainda assim tem seus problemas inclusive do vizinho barulhento. A terceira abordagem seria 1 banco de dados por "locador", isolação total de dados, muito bom. Mas, imagine a complexidade de se criar um banco de dados para cada locador? E a complexidade, segurança etc?

SQLite resolve tudo isso. É um arquivo, não tem senha ou login. É só criar e usar. É super rápido, podendo chegar a microsegundos (!), super fácil de replicar com litestream. SEM LATÊNCIA DE REDE. Ampla gama de plugins, inclusive de busca por vetor.

E a concorrência? Claro, SQLite não comporta concorrência de escrita, mas na escrita, em modo WAL, não bloqueia leitores. Tom Dyson em sua apresentação no DjangoCon Europe 2023 afirmou que mesmo sem WAL, SQLite aguentaria a carga da grande maioria dos sistemas.

E se você quer facilidade ainda maior, use Turso Cloud. É 100% compatível com SQLite, ou, é SQLite para produção como o divulgam. Você escreve no servidor (verdade única) e ele replica em quantos DB's estiverem sendo usados e ond estiverem sendo usados.

Isso é uma revolução para arquitetura multitenant, fazendo a abordagem 1 DB por "locador" totalmente viável e sem complexidade e garantindo a isolação total dos dados.

O Turso levou esse pensamento além. Agora, passou a se falar em 1 DB por usuário. Imagine? Banco de dados super rápidos, queries que chegam a microsegundos.

SQLite não é para produção? É para produção e serve para sistemas complexos.

É interessante como certos concensos errados (depreciados) se perpetuam na comunidade. Monolíticos (SSR com template engines) jamais devem ir à produção, SQLite não é para produção, entre outros. A revolução é feita por aqueles que fogem ao consenso de modo pensando. Pode ser que sua suposição esteja errada, mas vocẽ tentou. A suposição dos criadores do Turso estava certa e eles revolucionaram a arquitetura multitenant.

Estou prestes a colocar um produto ambicioso em produção e sua base é SQLite. Se será um sucesso o tempo dirá, mas não vou me render ao consenso.

Não seja repetidor do concenso, busque a verdade e a eficiência.