Embedded replicas no TursoDB

Para quem não sabe, o TursoDB é um banco de dados em nuvem distribuído, 100% compatível com SQLite. Ele foi construído sobre o libSQL, uma versão de código aberto do SQLite otimizada para desenvolvedores modernos.

A ideia da implementação de embed replicas: em vez da sua app fazer HTTP para o banco remoto a cada leitura, o libSQL mantém uma cópia local do banco (um arquivo .db) dentro do processo da aplicação.

Testei essa arquitetura num projeto de exemplo (repo no final) e o ganho de latência é real. Abaixo temos uma tabela de benchmark realizando 200 operações usando somente a implementação remota em comparação com a implementação com embed replicas:

Operação	Remoto	Embed Replica
Write	0.85 ops/s	-
Read	9.13 ops/s	1800.86 ops/s

Tivemos um ganho de 197x mais velocidade em operações de leitura, que unidos a um cache, pode melhorar ainda mais esses resultados. Mas vamos falar da funcionalidade:

Como funciona:
→ Leituras são sempre servidas localmente, em microssegundos
→ Escritas vão direto para o primário remoto (Turso Cloud)
→ Depois de uma escrita bem-sucedida, a réplica local é atualizada automaticamente — isso garante read-your-writes: quem escreveu já enxerga o próprio dado, mesmo sem chamar sync()
→ Outras réplicas se atualizam via sync() manual ou syncInterval periódico

Integração com Prisma: o driver adapter @prisma/adapter-libsql conecta o Prisma Client direto no libSQL, mantendo type-safety normal. O ponto de atenção é que Prisma Migrate não funciona direto contra o banco remoto (HTTP), então o fluxo é gerar a migration localmente com prisma migrate dev e aplicar via turso db shell.

Onde isso brilha: VPS/VMs com boa parte do tráfego sendo leitura, e cenários de conectividade instável (mobile, edge). Não é indicado para ambientes serverless sem filesystem.

Repo com a implementação: github.com/wesleyara/embbed-replicas-sample

#Turso #Prisma #SQLite #libSQL #BackendDevelopment