Turso: SQLite distribuído na edge para apps globais sem ops

Introdução ao Turso: O SQLite que transcende o mobile

O SQLite sempre foi o banco de dados favorito para aplicações mobile e embarcadas, mas sua arquitetura tradicional impõe limitações severas em aplicações web globais: single-writer, armazenamento estritamente local e zero suporte nativo a replicação distribuída. Para times que precisam de baixa latência global sem sacrificar a simplicidade do SQLite, surge o Turso — uma plataforma que transforma o SQLite em um banco de dados distribuído, executado na edge com replicação automática e zero gerenciamento de infraestrutura.

O diferencial do Turso está no libSQL, um fork open-source do SQLite que adiciona capacidades de replicação assíncrona, suporte a vetores e extensões customizadas. Com ele, desenvolvedores podem criar aplicações com leitura local instantânea em centenas de regiões, enquanto as escritas são coordenadas por um primário centralizado — tudo sem precisar configurar clusters, gerenciar failovers ou lidar com complexidade operacional.

Arquitetura Distribuída: Como o Turso funciona por baixo dos panos

O Turso utiliza um modelo de Embedded Replicas: cada edge node (seja um Cloudflare Worker, Vercel Edge Function ou servidor próprio) executa uma réplica local do banco SQLite. As leituras são atendidas diretamente dessa réplica, com latência tipicamente abaixo de 10ms. As escritas, por sua vez, são enviadas para o primário (Database Instance) e propagadas assincronamente para todas as réplicas.

A topologia do Turso distingue dois conceitos fundamentais:

  • Database Instance: O banco primário, responsável por todas as escritas. Vive em uma região específica.
  • Database Location: Réplicas geograficamente distribuídas, que sincronizam com o primário via libSQL.

O failover é automático: se o primário falhar, o Turso elege uma réplica como novo primário, garantindo continuidade sem intervenção manual.

Turso na Prática: Configuração e Primeiros Passos

Instalação e CLI

Primeiro, instale a CLI do Turso:

curl -sSf https://get.turso.tech | sh

Crie um banco de dados e configure réplicas:

turso auth login
turso db create my-global-db
turso db locations add my-global-db --locations gru,cdg,iad

Gere um token de acesso para sua aplicação:

turso db tokens create my-global-db

Conectando a partir de uma Edge Function (Cloudflare Workers)

import { createClient } from '@libsql/client/web';

const db = createClient({
  url: process.env.TURSO_DB_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN!,
});

export default {
  async fetch(request: Request): Promise<Response> {
    const result = await db.execute('SELECT * FROM products WHERE region = ?', ['us-east']);
    return new Response(JSON.stringify(result.rows), {
      headers: { 'Content-Type': 'application/json' },
    });
  },
};

Migrações e Schema

Use o turso db shell para executar comandos SQL diretamente:

turso db shell my-global-db
CREATE TABLE products (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT NOT NULL,
  region TEXT NOT NULL,
  price REAL NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_products_region ON products(region);

Para ambientes de produção, integre com ferramentas como Prisma ou Drizzle ORM, que já possuem suporte nativo ao Turso.

Estratégias de Dados para Aplicações Globais

Leitura Local, Escrita Centralizada

O padrão mais comum: réplicas em cada região atendem leituras localmente, enquanto escritas são enviadas ao primário. Ideal para catálogos de produtos, posts de blog ou qualquer workload com maioria de leituras.

-- Escrita sempre no primário (via URL do database instance)
await db.execute('INSERT INTO orders (user_id, total) VALUES (?, ?)', [userId, total]);

-- Leitura local (via URL da réplica mais próxima)
const products = await db.execute('SELECT * FROM products WHERE region = ?', [userRegion]);

Particionamento Geográfico (Sharding)

Para aplicações com alta taxa de escritas, divida os dados por região:

turso db create db_us --location iad
turso db create db_eu --location cdg
turso db create db_asia --location hkg

Cada banco atende exclusivamente sua região, eliminando a latência de replicação.

Consistência Eventual vs. Forte

O Turso oferece consistência eventual por padrão (leitura local imediata, escrita propagada em segundos). Para operações que exigem consistência forte, use o parâmetro sync:

await db.execute('INSERT INTO inventory (product_id, stock) VALUES (?, ?)', [productId, stock], { sync: true });

Isso força a escrita a aguardar a confirmação do primário.

Casos de Uso Reais: Onde o Turso Brilha

Aplicações de Comércio Global

Um e-commerce com clientes nos EUA, Europa e Ásia pode ter réplicas em cada continente. O catálogo de produtos é lido localmente, enquanto pedidos são escritos no primário (EUA). O carrinho de compras pode ser armazenado na réplica local com sincronização eventual.

SaaS Multi-tenant

Cada cliente recebe um banco Turso isolado, com réplicas apenas nas regiões onde seus usuários estão. O isolamento é total, e a replicação é configurada por tenant.

Aplicações de Tempo Real (Jogos, Chat)

O Turso funciona como cache de estado de sessão. Cada partida de jogo ou sala de chat mantém seu estado em uma réplica local, com escritas rápidas e sincronização global eventual.

Comparação Técnica: Turso vs. Alternativas no Ecossistema

Característica Turso (SQLite) PlanetScale (MySQL) Neon (PostgreSQL) Supabase (PostgreSQL)
Modelo de replicação Embedded replicas (leitura local) Vitess (sharding) Compute-Storage separados Streaming replication
Latência na edge <10ms (leitura local) 50-100ms (escrita remota) 30-80ms (cold start) 40-120ms
Custo inicial Gratuito (9GB) $39/mês $19/mês $25/mês
Complexidade operacional Zero (sem ops) Média (configuração Vitess) Baixa Baixa
Suporte a transações Sim (ACID local) Sim (ACID global) Sim (ACID global) Sim (ACID global)
Extensões vetoriais Sim (libSQL) Não Não Não

Boas Práticas, Armadilhas e Operações “Sem Ops”

Gerenciamento de Conexões

Em ambientes serverless, evite criar conexões por requisição. Use um pool global:

import { createClient } from '@libsql/client/web';

let db: ReturnType<typeof createClient> | null = null;

export function getDb() {
  if (!db) {
    db = createClient({
      url: process.env.TURSO_DB_URL!,
      authToken: process.env.TURSO_AUTH_TOKEN!,
    });
  }
  return db;
}

Estratégias de Backup e Restore

O Turso oferece snapshots automáticos diários e point-in-time recovery (PITR) para os últimos 7 dias. Para restaurar:

turso db restore my-global-db --timestamp 2024-01-15T10:30:00Z

Monitoramento e Alertas

Métricas essenciais disponíveis no dashboard do Turso:

  • Latência de replicação (ideal <500ms)
  • Taxa de erros de conexão
  • Uso de armazenamento por réplica
  • Número de conexões simultâneas

Configure alertas via webhook ou integração com Datadog/Prometheus.

Conclusão e Roadmap Futuro

O Turso representa a evolução natural do SQLite para a era da edge computing. Ele combina a simplicidade e performance do banco embedded mais popular do mundo com a escalabilidade global que aplicações modernas exigem — tudo sem a complexidade operacional de bancos tradicionais.

Limitações atuais incluem a falta de suporte nativo a triggers complexos e stored procedures, além da latência de replicação para escritas (tipicamente 1-3 segundos). Para a maioria dos casos de uso, porém, o compromisso é mais que aceitável.

O roadmap inclui integração nativa com vetores para AI/ML, melhorias em transações distribuídas (suporte a two-phase commit) e um ecossistema mais robusto de ferramentas de migração e observabilidade. Para times que buscam performance global sem sacrificar a simplicidade do SQLite, o Turso é, hoje, a plataforma mais promissora do mercado.

Referências