Criar Banco de Dados no SQLite: gerando o arquivo .db

Um banco SQLite é só um arquivo

Se você já usou MySQL ou Postgres, está acostumado a rodar CREATE DATABASE meuapp; e deixar o servidor cuidar dos detalhes nos bastidores. No SQLite a história é outra. Não tem servidor. Não existe o comando CREATE DATABASE. Um banco de dados é apenas um arquivo comum em disco — normalmente com extensão .db, .sqlite ou .sqlite3, mas isso é só convenção.

Para criar um, basta apontar a ferramenta sqlite3 para um nome de arquivo que ainda não existe:

sqlite3 mydata.db

É isso. Se mydata.db não existir, o SQLite já está pronto para criar o arquivo. Se existir, ele simplesmente abre. O comando é o mesmo nos dois casos. O modelo mental aqui é mais parecido com "abrir um documento" do que com "subir um servidor de banco de dados".

O arquivo só aparece quando você grava alguma coisa

Tem um detalhe que costuma pegar muita gente de surpresa. Rode o comando acima, digite .quit e dê uma olhada no diretório. O arquivo não está lá.

O SQLite é preguiçoso. Ele não se dá ao trabalho de criar o arquivo no disco enquanto não houver nada para colocar dentro dele. Na hora em que você cria uma tabela ou faz commit de algum dado, o arquivo aparece:

CREATE TABLE notes (
    id INTEGER PRIMARY KEY,
    body TEXT
);

Agora o arquivo mydata.db está gravado em disco. Até essa primeira escrita, o "banco" existe apenas na memória da conexão. Isso às vezes confunde — e às vezes ajuda, já que uma sessão abortada não deixa rastros.

Criando um banco SQLite pela linha de comando

O fluxo completo, partindo de um terminal limpo:

$ sqlite3 mydata.db
SQLite version 3.45.0
Enter ".help" for usage hints.
sqlite> CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT);
sqlite> .databases
main: /home/you/mydata.db r/w
sqlite> .quit

Alguns comandos úteis do CLI enquanto você está por lá:

• .databases — lista os bancos anexados e o caminho dos arquivos.
• .tables — mostra as tabelas do banco atual.
• .schema — exibe os comandos CREATE TABLE de tudo que existe.
• .quit — sai do shell.

Se você já está dentro do sqlite3 sem nenhum arquivo aberto (ou seja, abriu sem passar argumento), dá pra anexar um arquivo com .open:

sqlite> .open mydata.db

Mesma regra: cria se não existir, abre se já existir.

O "IF NOT EXISTS" já vem embutido

Quem vem de outros bancos costuma ter aquela dúvida: e se o arquivo já existir? Vou sobrescrever sem querer? Pode ficar tranquilo. Abrir um arquivo existente apenas abre ele, sem apagar nada. O equivalente mais próximo do CREATE DATABASE IF NOT EXISTS aqui é simplesmente... abrir o arquivo. O SQLite resolve os dois casos com o mesmo comando.

Agora, se você realmente quer começar do zero, basta apagar o arquivo antes:

rm mydata.db
sqlite3 mydata.db

Mas pense bem antes de fazer isso. Não tem desfazer, e também não existe ferramenta administrativa que recupere o arquivo.

Criando um banco SQLite com Python

Na prática, você quase nunca vai ficar no CLI — o normal é criar o banco direto pelo código da aplicação. O Python já vem com o módulo sqlite3 na biblioteca padrão, então não precisa instalar nada:

-- Código Python equivalente:
-- import sqlite3
-- conn = sqlite3.connect("mydata.db")
-- conn.execute("CREATE TABLE notes (id INTEGER PRIMARY KEY, body TEXT)")
-- conn.commit()
-- conn.close()

CREATE TABLE notes (
    id INTEGER PRIMARY KEY,
    body TEXT
);

sqlite3.connect("mydata.db") segue a mesma lógica da CLI: cria o arquivo se ele não existir e abre se já estiver lá. Todos os outros bindings de linguagem (better-sqlite3 do Node, o driver database/sql do Go, o rusqlite do Rust e por aí vai) funcionam do mesmo jeito — no fim das contas, todos são wrappers em cima da mesma biblioteca C.

Um atalho específico do Python: passar ":memory:" como caminho cria um banco que vive inteiramente na RAM e some quando você fecha a conexão. Falaremos disso na próxima página.

Onde colocar o arquivo .db?

Como o banco é um arquivo, "onde eu salvo isso?" é uma pergunta legítima. Algumas dicas práticas:

• Para uma aplicação: em algum lugar dentro do diretório de dados do usuário ou no diretório de trabalho do seu app. Evite deixar o arquivo ao lado do executável em sistemas onde aquele caminho não tem permissão de escrita.
• Para um projeto: na raiz do repositório ou numa pasta data/. Coloque no .gitignore se ele guarda estado local — versionar um banco binário no Git costuma dar dor de cabeça.
• Para testes: use :memory: ou um arquivo temporário. Rápido e se limpa sozinho.

Permissões também importam. O usuário que executa o processo precisa ter acesso de leitura e escrita tanto no arquivo quanto na pasta onde ele está (o SQLite cria arquivos de lock ao lado do banco durante as escritas).

Um teste rápido pra garantir que tudo funciona

Para confirmar que o fluxo todo está funcionando de ponta a ponta:

CREATE TABLE greetings (
    id INTEGER PRIMARY KEY,
    message TEXT NOT NULL
);

INSERT INTO greetings (message) VALUES ('olá'), ('mundo');

SELECT * FROM greetings;

Você deve ver duas linhas no retorno. Se funcionou, é porque o arquivo do banco existe, o schema está nele e os dados são consultáveis. E é basicamente isso o que significa "criar um banco" no SQLite — sem servidor, sem usuários, sem tabela de permissões. É só um arquivo.

A seguir: bancos SQLite em memória

A mesma chamada sqlite3.connect(...) que cria um arquivo pode, com o argumento certo, criar um banco que nunca chega a tocar no disco. Bancos em memória são a forma mais rápida de rodar testes, prototipar um schema ou guardar dados temporários. É o que vem a seguir.