Você já pensou no fato de que o navegador que você abre todos os dias, o software de comunicação no seu celular e até a ferramenta de notas no seu computador ocultam o mesmo banco de dados leve?
Ele não exige que você instale nenhum software de servidor, não precisa de configurações de conta ou senha e nem precisa de conexão com a Internet. É simplesmente um arquivo, que repousa silenciosamente no seu disco rígido, pronto para atendê-lo a qualquer momento.
Essa existência discreta é o SQLite.
O que é o SQLite? O banco de dados mais amplamente implantado no mundo
SQLite é um mecanismo de banco de dados relacional embarcado escrito em C.
Ele não possui um processo de servidor independente, mas é diretamente embarcado em sua aplicação para ser executado.
Isso é completamente diferente do PostgreSQL ou MySQL com os quais você está familiarizado. Os bancos de dados tradicionais são servidores independentes executados separadamente, e seu programa deve “comunicar-se” com eles por meio de um protocolo de rede (TCP/IP).
But SQLite é diferente; é simplesmente um bloco de código que roda diretamente dentro da sua aplicação, lendo e gravando aquele arquivo .db no seu disco rígido.
| Dimensão de comparação | SQLite (Embarcado) | PostgreSQL (Cliente-Servidor) |
|---|---|---|
| Modo de operação | Diretamente embarcado na aplicação, sem servidor independente | Processo de servidor independente, via conexão de rede |
| Requisitos de config. | Configuração zero, sem instalação, sem credenciais | Requer instalação, configuração de conta/senha e firewall |
| Armaz. de dados | Arquivo único multiplataforma | Múltiplos arquivos sob o diretório do servidor |
| Método de backup | Copiar diretamente aquele arquivo | Requer ferramentas dedicadas como pg_dump |
É precisamente por causa dessa característica de “plug-and-play” que o SQLite se tornou o mecanismo de banco de dados mais implantado no mundo.
Desde os sistemas operacionais Android e iOS, navegadores Chrome e Firefox, até o Adobe Lightroom, WhatsApp e até mesmo o sistema de voo do Airbus A350, ele está em toda parte.
Usando o SQLite no Node.js
Se você é um desenvolvedor Node.js, usar o SQLite é extremamente simples. Você não precisa instalar nenhum software de servidor de banco de dados no seu computador, precisa apenas instalar um pacote npm para começar.
As opções mais comumente usadas na indústria hoje:
| Nome do pacote | Características | Cenário recomendado |
|---|---|---|
sqlite3 |
O mais tradicional, suporta APIs assíncronas | Quando precisa lidar com muitas tarefas assíncronas simultaneamente |
better-sqlite3 |
Excelente desempenho, design de API intuitivo, extremamente rápido | Recomendação principal, para eficiência de desenvolvimento e velocidade de execução |
Criar um banco de dados e consultá-lo com o better-sqlite3 leva menos de cinco minutos:
const Database = require('better-sqlite3');
const db = new Database('my_project.db');
db.prepare('CREATE TABLE IF NOT EXISTS users (name TEXT, age INTEGER)').run();
const insert = db.prepare('INSERT INTO users (name, age) VALUES (?, ?)');
insert.run('John', 25);
const user = db.prepare('SELECT * FROM users WHERE name = ?').get('John');
console.log(user); // { name: 'John', age: 25 }
Se o arquivo não existir, o
better-sqlite3o criará automaticamente para você.
O SQLite suporta uma sintaxe SQL mais poderosa do que você imagina
Muitas pessoas pensam que o SQLite é muito básico, mas ele suporta a grande maioria da sintaxe SQL padrão, incluindo muitos recursos avançados:
| Categoria de sintaxe | Itens suportados |
|---|---|
| Operações básicas | SELECT, INSERT, UPDATE, DELETE |
| Definição de dados | CREATE TABLE, CREATE INDEX, CREATE VIEW |
| Consultas avançadas | WITH (CTEs recursivas), Funções de janela (Window Functions) |
| Tratamento de conflito | UPSERT (INSERT ... ON CONFLICT DO UPDATE) |
| Processamento de JSON | Funções integradas como json_extract, json_array, json_object, etc. |
| Controle de transação | BEGIN, COMMIT, ROLLBACK, SAVEPOINT |
| Consultas de junção | INNER JOIN, LEFT JOIN, RIGHT JOIN e FULL OUTER JOIN |
A filosofia central do SQLite é “pequeno e bonito”, suportando a maioria das capacidades SQL que você precisa no dia a dia, mantendo-se extremamente leve.
Onde estão os limites do SQLite?
A leveza tem um preço. Se compararmos o SQLite a uma mercearia hipster com apenas um caixa de pagamento, o PostgreSQL seria um Costco equipado com 50 caixas registradoras.
1. Congestionamento de gravação
Quando o SQLite grava dados, ele bloqueia todo o arquivo do banco de dados.
Imagine um restaurante com apenas um banheiro: 100 pessoas podem olhar o cardápio do lado de fora (ler) ao mesmo tempo, mas contanto que 1 pessoa entre e tranque a porta (gravar), todas as outras só podem fazer fila e esperar.
Embora a ativação do modo WAL (Write-Ahead Logging) possa melhorar o desempenho de leitura/gravação simultânea, fundamentalmente ainda não é possível realizar gravações simultâneas multithread em diferentes linhas de dados.
2. Não é possível distribuir em múltiplos servidores
A essência do SQLite é um arquivo físico. Se o seu sistema for implantado em múltiplos servidores (escala horizontal), esses servidores não podem compartilhar o mesmo arquivo com segurança.
3. Falta de gerenciamento de permissões detalhado
O SQLite não possui o conceito de “contas de usuário”. Qualquer pessoa que possa ler esse arquivo .db no nível do sistema operacional pode ver e modificar todos os dados.
Para sistemas de negócios que exigem auditorias rigorosas de dados pessoais, isso é inaceitável.
SQLite vs. PostgreSQL: Decisões de seleção de tecnologia
As ferramentas não são boas nem ruins, apenas adequadas ou não. Aqui está um checklist definitivo para ajudá-lo a tomar decisões:
| Pergunta | Resposta “Sim” → Escolha o SQLite | Resposta “Não” → Escolha o PostgreSQL |
|---|---|---|
| Existe apenas um servidor backend, ou ele roda totalmente de forma local? | Sim | Não (requer escala horizontal, múltiplas máquinas) |
| O comportamento do sistema é dominado pela leitura, sem gravações simultâneas de alta frequência? | Sim | Não (os usuários competirão para gravar simultaneamente) |
| Não precisa de permissões de conta de banco de dados detalhadas ou indexação avançada? | Sim | Não (depende fortemente de recursos avançados) |
Comparações de cenários mais específicos:
| Cenário | Seleção recomendada | Razão |
|---|---|---|
| Software desktop, Aplicativos móveis, Dispositivos IoT | SQLite | Os dados viajam com o dispositivo, sem instalação |
| Blogs pessoais, Sites de portfólio/institucionais | SQLite | Muita leitura, pouca gravação, economiza custos de manutenção de servidor |
| Desenvolvimento rápido de protótipos, Demos | SQLite | Basta criar um arquivo para começar |
| Fóruns comunitários, Plataformas de comércio eletrônico | PostgreSQL | Alta concorrência de gravação, requer bloqueio a nível de linha |
| Implantação distribuída em múltiplos servidores | PostgreSQL | Precisa compartilhar a fonte de dados entre diferentes máquinas |
| Sistemas sensíveis como médicos ou financeiros | PostgreSQL | Requer controle estrito de permissões baseado em funções |
O seu banco de dados é um bloco de notas de bolso ou uma central telefônica central?
Se os dados são “monomáquina, estáticos, de proprietário único”, escolha o SQLite para desfrutar de extrema leveza e liberdade;
Se os dados são “na nuvem, dinâmicos, altamente interativos”, deixe o PostgreSQL assumir o controle.
A filosofia central do SQLite é “um componente interno da aplicação”, enquanto o PostgreSQL se posiciona como “um centro independente da arquitetura do sistema”.
A próxima vez que tomar uma decisão de arquitetura, não se apresse em sacar o PostgreSQL. Pergunte-se primeiro:
“O meu banco de dados é um bloco de notas de bolso ou uma central telefônica central?”
Quando a resposta estiver clara, a escolha naturalmente se tornará óbvia.