Por que SQLite

Quando alguém ouve que uma suíte de marketing em produção roda sobre SQLite, a primeira reação costuma ser desconfiança. SQLite tem fama de banco "de brinquedo" — bom para o protótipo, bom para o app de celular, mas não para "produção de verdade", onde supostamente é obrigatório um Postgres num cluster gerenciado.

Essa fama está desatualizada, e a desconfiança esconde uma inversão importante. A LaunchWithAgency não usa SQLite apesar de querer ser séria. Ela usa SQLite porque a seriedade dela é um tipo específico: a de uma suíte cuja proposta inteira — cinco produtos, um banco — só fica simples, barata e confiável se o banco for um arquivo. Este artigo é a defesa dessa escolha.

O que a stack realmente é

A LaunchWithAgency roda sobre seis peças, e a lista inteira cabe num parágrafo. Bun como runtime de JavaScript, servindo HTTP. Elysia como framework de rotas sobre o Bun. SQLite, via o bun:sqlite embutido, como banco. Drizzle como ORM — schemas declarativos, migrations imperativas. Better Auth para login com email e senha. Resend para o email transacional sair.

Não há um cluster. Não há um build step de servidor. Não há uma camada de cache separada, uma fila de mensagens dedicada, um serviço de busca à parte. A aplicação é um processo que fala HTTP e lê um arquivo de banco. Essa magreza não é falta de ambição — é a ambição. O princípio declarado é "software que cabe na cabeça": um sistema que uma pessoa consegue entender por inteiro é um sistema que ela consegue operar, depurar e evoluir sem medo.

SQLite em produção, sem o folclore

Vamos enfrentar o folclore direto. Três afirmações populares sobre SQLite, e o que de fato é verdade.

"SQLite não aguenta produção." SQLite é, por várias medidas, o banco mais usado do planeta — ele roda dentro de cada navegador, cada celular, incontáveis sistemas embarcados. O que ele não é desenhado para fazer é um padrão específico: escritas concorrentes massivas, de muitos clientes ao mesmo tempo, contra o mesmo banco. Para leituras concorrentes, ele é excelente. E uma suíte de marketing é uma carga esmagadoramente de leitura: páginas servidas, posts renderizados, dashboards consultados. As escritas — uma nova inscrição, um log de email, uma execução de flow — são frequentes mas não massivas. SQLite, com o modo WAL ligado, atende essa carga com folga.

"Você vai precisar migrar para Postgres quando crescer." Essa frase trata escala como se houvesse uma só. A escala que importa para a LaunchWithAgency é a operação de marketing de uma agência ou um time de produto — assinantes na casa dos milhares ou dezenas de milhares, não dezenas de milhões. Nessa faixa, o banco nunca é o gargalo, e a migração antecipada para Postgres é resolver um problema que você não tem pagando com um problema que você passa a ter: complexidade operacional. Projetar para a escala que você realmente vive não é miopia — é engenharia honesta.

"Um arquivo único é frágil." É o oposto. Um arquivo único é a coisa mais robusta de operar que existe. O backup é cp. A inspeção é abrir o arquivo com a ferramenta de linha de comando do SQLite e rodar SQL. A portabilidade é total: o banco inteiro viaja como um anexo de email. Compare com fazer backup, inspecionar e migrar um cluster Postgres gerenciado — e fica claro qual dos dois é frágil de operar.

> A pergunta "SQLite aguenta produção?" é a pergunta errada. A certa é "qual produção?" — e para a produção de uma operação de marketing, SQLite não só aguenta, ele é a escolha mais sólida.

A stack enxuta é o que torna o banco único viável

Aqui está a conexão que amarra esta escolha à proposta inteira da LaunchWithAgency.

A promessa central da suíte é integração radical: cinco produtos lendo e escrevendo o mesmo banco, sem cola, sem sincronização. Essa promessa é fácil de fazer e difícil de cumprir — a menos que o banco seja simples o suficiente para que "cinco produtos no mesmo banco" não introduza uma operação infernal.

Com SQLite, "o mesmo banco" é literalmente o mesmo arquivo. Os cinco produtos abrem data/local.db e pronto. Não há um servidor de banco para configurar, conexões para repartir, pools para dimensionar, permissões de schema para coordenar entre produtos. A integração de cinco produtos só é trivial porque o banco é um arquivo. Se a suíte rodasse sobre um cluster Postgres, a parte difícil não seria escrever os produtos — seria operar a infraestrutura compartilhada que os une. SQLite faz essa parte difícil desaparecer.

O mesmo vale para o resto da stack. Sem build step de servidor, o código que você lê é o código que roda. Com Drizzle, o schema é declarativo e legível — as próprias tabelas que descrevemos nos outros artigos são arquivos JavaScript curtos. Com migrations imperativas rodando no boot, subir o sistema é subir o sistema; não há um passo de orquestração separado. Cada peça da stack foi escolhida pela mesma razão: para que a suíte inteira caiba na cabeça de quem a opera.

Enxuto é uma característica, não um estágio

Existe uma narrativa comum no software segundo a qual "enxuto" é uma fase — o estado provisório de um produto jovem, que será naturalmente substituído por algo "robusto" quando ele amadurecer. Robusto, nessa narrativa, é sinônimo de complexo.

A LaunchWithAgency rejeita essa narrativa explicitamente. Enxuto aqui não é um estágio a ser superado — é um compromisso de design a ser defendido. Bun, Elysia, SQLite, Drizzle, Better Auth, Resend não são andaimes temporários esperando por um cluster. São a forma final pretendida, porque a forma final pretendida é um sistema que uma pessoa entende inteiro.

Isso é uma vantagem de produto, não só de engenharia. Um sistema simples tem menos lugares para um bug se esconder. Um banco que é um arquivo tem um modelo de backup que ninguém erra. Uma stack sem cluster tem uma conta de infraestrutura previsível. E uma operação que cabe na cabeça é uma operação que evolui rápido — porque ninguém tem medo de mexer no que entende.

> A escolha de SQLite não é onde a LaunchWithAgency economiza. É onde ela decide o que quer ser: uma suíte que você compreende, não uma que você apenas confia.