Crear base de datos en SQLite: nuevo archivo .db

Una base de datos SQLite es solo un archivo

Si vienes de MySQL o Postgres, estarás acostumbrado a lanzar un CREATE DATABASE myapp; y dejar que el servidor se encargue de registrar la nueva base de datos por detrás. En SQLite la cosa no funciona así. No hay servidor. No existe la sentencia CREATE DATABASE. Una base de datos es, sencillamente, un archivo común y corriente en el disco, normalmente con extensión .db, .sqlite o .sqlite3, aunque la extensión es solo una convención.

Para crear una base de datos SQLite desde cero, basta con apuntar la herramienta sqlite3 a un nombre de archivo que todavía no exista:

sqlite3 mydata.db

Y ya está. Si mydata.db no existe, SQLite lo crea sin problema. Si ya existe, lo abre. El mismo comando sirve para ambos casos. El modelo mental se parece más a "abrir un documento" que a "levantar un servidor de base de datos".

El archivo no aparece hasta que escribes algo

Aquí hay un detalle que suele despistar. Ejecuta el comando de arriba, escribe .quit y revisa tu directorio. El archivo no está.

SQLite es perezoso. No se molesta en crear el archivo en disco hasta que hay algo que guardar dentro. En el momento en que creas una tabla o haces commit de datos, el archivo aparece:

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

Ahora mydata.db existe en disco. Hasta esa primera escritura, la "base de datos" vive únicamente en la memoria de la conexión. Esto a veces confunde — y a veces resulta útil, porque significa que una sesión interrumpida no deja rastro.

Crear una base de datos SQLite desde la terminal

El flujo completo partiendo de una shell limpia:

$ 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

Algunos comandos útiles de la CLI mientras estés dentro:

• .databases — muestra las bases de datos conectadas y sus rutas de archivo.
• .tables — lista las tablas de la base de datos actual.
• .schema — muestra las sentencias CREATE TABLE de todo.
• .quit — salir.

Si ya estás dentro de sqlite3 sin ningún archivo abierto (porque lo arrancaste sin argumentos), puedes asociar un archivo con .open:

sqlite> .open mydata.db

Misma regla: si no existe, lo crea; si ya existe, lo abre.

El "if not exists" viene de fábrica

Una duda típica que llega de otros motores: ¿y si el archivo ya está? ¿Lo voy a pisar? Tranquilo, no. Abrir un archivo existente simplemente lo abre. No se sobrescribe nada. Lo más parecido a un CREATE DATABASE IF NOT EXISTS aquí es, literalmente... abrir el archivo. SQLite resuelve los dos casos con el mismo comando.

Si lo que quieres es empezar desde cero, borra el archivo antes:

rm mydata.db
sqlite3 mydata.db

Eso sí, asegúrate de que es lo que quieres hacer. No hay deshacer, ni herramienta de administración para recuperarla.

Crear una base de datos SQLite desde Python

La mayoría de las veces no vas a estar en la CLI: vas a crear las bases de datos desde el código de tu aplicación. Python trae el módulo sqlite3 en su librería estándar, así que no necesitas 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") sigue la misma lógica que la CLI: si el archivo no existe lo crea, y si existe lo abre. El resto de bindings para otros lenguajes (better-sqlite3 en Node, el driver database/sql de Go, rusqlite en Rust, etc.) se comportan igual, porque todos envuelven la misma librería en C por debajo.

Un atajo específico de Python: si pasas ":memory:" como ruta, obtienes una base de datos SQLite en memoria que vive enteramente en RAM y desaparece al cerrar la conexión. Eso lo vemos en la siguiente página.

¿Dónde conviene guardar el archivo .db?

Como la base de datos es un archivo, la pregunta "¿y dónde lo dejo?" es totalmente válida. Algunas reglas prácticas:

• Para una aplicación: en algún sitio dentro del directorio de datos del usuario o del directorio de trabajo de la app. Evita ponerlo junto al ejecutable en sistemas donde esa ruta no tiene permisos de escritura.
• Para un proyecto: en la raíz del repo o dentro de una carpeta data/. Agrégalo al .gitignore si guarda estado local; subir una base de datos binaria a Git casi nunca termina bien.
• Para tests: usa :memory: o un archivo temporal. Rápido y se limpia solo.

Los permisos también cuentan. El usuario que ejecuta el proceso necesita acceso de lectura y escritura tanto al archivo como al directorio que lo contiene (SQLite crea archivos de lock junto a la base de datos durante las escrituras).

Una prueba rápida para verificar que todo funciona

Para comprobar que el flujo completo funciona de punta a punta:

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

INSERT INTO greetings (message) VALUES ('hola'), ('mundo');

SELECT * FROM greetings;

Deberías ver dos filas de vuelta. Si funciona, tu archivo de base de datos existe, tu esquema está dentro y los datos se pueden consultar. Esa es toda la historia de "crear una base de datos" en SQLite: sin servidor, sin usuarios, sin tabla de permisos. Solo un archivo.

Lo que viene: bases de datos en memoria

La misma llamada a sqlite3.connect(...) que crea un archivo puede, con el argumento adecuado, crear una base de datos que nunca toca el disco. Las bases de datos en memoria son la forma más rápida de correr pruebas, prototipar un esquema o guardar datos temporales. Lo vemos a continuación.