SQLite vs MySQL: qual banco de dados escolher?

Dois formatos bem diferentes de banco de dados

SQLite e MySQL falam SQL e armazenam linhas em tabelas, mas o jeito como cada um se encaixa em um sistema é completamente diferente. O SQLite é uma biblioteca: sua aplicação faz o link com ele e lê direto de um arquivo no disco. Já o MySQL é um servidor: um processo separado com o qual você se conecta via socket ou pela rede.

Essa única diferença muda tudo o que vem depois: como você instala cada um, quantas escritas simultâneas são possíveis, como faz backup e como sobe pra produção. Quase toda dúvida sobre SQLite ou MySQL, no fundo, é uma dúvida sobre banco embarcado versus cliente-servidor.

-- SQLite: abra um arquivo e você tem um banco de dados.
sqlite3 app.db

-- MySQL: conecte-se a um servidor em execução.
mysql -h localhost -u root -p

O comando do SQLite abre (ou cria) um arquivo. Já o do MySQL abre uma conexão com um processo que precisa estar rodando, configurado e aceitando logins.

Arquitetura: embutido vs cliente-servidor

Em uma aplicação com SQLite, o motor do banco roda dentro do seu programa. Não tem porta, nem daemon, nem systemctl start. Uma chamada à biblioteca sqlite3 lê e escreve páginas direto em um arquivo no disco.

O MySQL é o oposto. O servidor mysqld guarda os dados, gerencia conexões, aplica permissões, executa o planejador de consultas e cuida dos bloqueios. Sua aplicação é um cliente que manda strings SQL pela rede e recebe linhas de resultado de volta.

Na prática, isso significa:

• Implantação. O SQLite vai junto com sua aplicação — um binário, um arquivo. O MySQL exige um servidor separado para instalar, proteger, monitorar e fazer backup.
• Acesso pela rede. O MySQL expõe uma porta, então vários servidores de aplicação podem se conectar ao mesmo banco. O SQLite parte do princípio de que existe um processo (ou alguns processos cooperando) na mesma máquina.
• Permissões. O MySQL tem usuários, papéis e comandos GRANT. No SQLite, o único controle de permissão é a permissão de arquivo do sistema operacional sobre o arquivo do banco.

Nenhuma das duas formas é "melhor". Cada uma resolve um problema diferente.

Concorrência e escritas

É aqui que os dois realmente se separam. O motor InnoDB do MySQL faz bloqueio em nível de linha — várias conexões conseguem escrever em linhas diferentes ao mesmo tempo sem travar umas às outras.

O SQLite serializa as escritas no nível do banco inteiro. Só um escritor por vez, ponto final. Os leitores podem rodar em paralelo com o escritor (principalmente no modo WAL), mas um segundo escritor precisa esperar a vez.

-- SQLite: isso funciona bem para muitos leitores, um escritor por vez.
PRAGMA journal_mode = WAL;

-- MySQL: muitos escritores, bloqueio refinado.
-- (Sem configuração especial — o InnoDB faz isso por padrão.)

Para um app com um ou dois processos fazendo escritas modestas — uma ferramenta desktop, um app mobile, um CMS pequeno — as escritas serializadas do SQLite costumam ser rápidas o suficiente pra você nem perceber. Já em um serviço web movimentado, com centenas de conexões inserindo pedidos ou atualizando sessões ao mesmo tempo, o lock por linha do MySQL é o que separa o "tudo certo" do "tudo na fila esperando o mesmo cadeado".

Tipos de dados

O MySQL tem uma lista longa e rigorosa de tipos: TINYINT, INT, BIGINT, VARCHAR(n), DATETIME, DECIMAL(p,s), BLOB, JSON, entre vários outros. Se você declarar uma coluna como INT, o MySQL vai recusar uma string.

O SQLite, por outro lado, trabalha com type affinity (afinidade de tipo). Os tipos das colunas funcionam como sugestões, e não como regras impostas. Dá pra colocar uma string em uma coluna INTEGER que o SQLite armazena numa boa (a não ser que você opte pelas tabelas STRICT, disponíveis a partir da versão 3.37).

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    price REAL
);

INSERT INTO products (name, price) VALUES ('Café', 3.50);
INSERT INTO products (name, price) VALUES ('Chá', '2.75');  -- string em uma coluna REAL

SELECT id, name, price, typeof(price) FROM products;

As duas linhas são inseridas sem erro. Essa flexibilidade ajuda quando você está prototipando, mas pega de surpresa quem espera segurança de tipos no nível do banco. Use tabelas STRICT quando quiser uma validação parecida com a do MySQL dentro do SQLite.

Diferenças de sintaxe que você vai encontrar na prática

A maior parte do SQL básico — SELECT, JOIN, WHERE, GROUP BY — é idêntica nos dois. As diferenças se concentram em alguns pontos específicos:

• Chaves primárias com auto-incremento. No SQLite, basta INTEGER PRIMARY KEY (que já faz auto-incremento por padrão). No MySQL, é INT AUTO_INCREMENT PRIMARY KEY.
• Aspas em identificadores. O MySQL aceita crases para identificadores (`table`). O SQLite usa aspas duplas ("table"), seguindo o padrão SQL.
• Funções de data. O MySQL tem NOW(), CURDATE() e DATE_ADD(). Já o SQLite usa datetime('now'), date('now') e datetime('now', '+1 day').
• Sintaxe do LIMIT. Os dois aceitam LIMIT n OFFSET m, então aqui não tem dor de cabeça.
• Booleanos. O MySQL tem BOOLEAN (que é um apelido para TINYINT(1)). O SQLite guarda booleanos como 0 e 1 em colunas INTEGER.

-- MySQL
CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    created_at DATETIME DEFAULT NOW()
);

-- SQLite
CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    created_at TEXT DEFAULT (datetime('now'))
);

Mesma ideia, palavras-chave diferentes. O modelo mental se mantém; a sintaxe pede um pequeno ajuste.

Performance: depende da pergunta

"SQLite é mais rápido que MySQL?" não tem uma resposta única.

Para um único processo lendo e escrevendo localmente, o SQLite costuma ser mais rápido — não tem ida e volta na rede, não tem comunicação entre processos, não tem um parser de queries rodando em outro espaço de endereçamento. Um SELECT no SQLite é praticamente uma chamada de função.

Já para muitas conexões concorrentes escrevendo no mesmo banco, o MySQL leva vantagem por causa do bloqueio em nível de linha. O modelo de escritor único do SQLite faz a contenção aparecer rápido nesse tipo de carga.

Para cargas com muita leitura e poucas escritas, com o modo WAL ativado, o SQLite escala surpreendentemente bem — os leitores não bloqueiam uns aos outros nem o único escritor. Tem muito site em produção servindo tráfego real em cima de SQLite.

Não escolha com base em benchmark aleatório que você leu na internet. Escolha com base no seu padrão real de acesso.

Quando cada um é a escolha certa

Vá de SQLite quando:

• O banco mora junto de uma aplicação só (app mobile, ferramenta desktop, CLI, site pequeno).
• Você quer deploy sem configuração — basta enviar o arquivo.
• As leituras superam de longe as escritas, ou as escritas são esporádicas.
• Você precisa de um banco de testes embutido que replique o SQL de produção.
• Você está prototipando e ainda não quer se preocupar com servidor.

Vá de MySQL quando:

• Vários servidores de aplicação precisam compartilhar o mesmo banco.
• Você tem muitos escritores concorrentes.
• Você precisa de permissões de usuário detalhadas e gerenciamento de papéis.
• Você está montando uma stack (LAMP, configurações gerenciadas comuns na nuvem) que já espera MySQL.
• Ferramental operacional — replicação, recuperação ponto a ponto, monitoramento — é requisito obrigatório.

Uma regra de bolso: se você descreveria sua necessidade de armazenamento como "uma aplicação, um disco", o SQLite provavelmente dá conta. Se descreveria como "um serviço, com operadores cuidando", parta para o MySQL (ou PostgreSQL).

Migrar de um para o outro

Começar no SQLite e migrar para o MySQL depois é um caminho batido — e um plano perfeitamente válido. Os schemas se traduzem com pequenos ajustes, e os dados saem limpinhos via .dump no CLI do SQLite. Você vai gastar tempo basicamente acertando a sintaxe de auto-incremento, funções de data e algumas features específicas do SQLite (índices parciais com formato estranho, tabelas WITHOUT ROWID, tabelas STRICT) que não têm equivalente direto no MySQL.

O caminho contrário — MySQL para SQLite — é menos comum, mas também é viável, normalmente para análise offline, cópias embutidas de um subconjunto dos dados ou fixtures de teste.

A conclusão: escolher SQLite hoje não te prende. O SQL que você escreve é portável, e o seu conhecimento também.

A seguir: SQLite vs PostgreSQL

A comparação com MySQL é a mais comum, mas o PostgreSQL é o outro banco que você sempre vê emparelhado com o SQLite — e ali as diferenças mudam de figura. É o assunto da próxima página.