SQLite on Dev TLDRLSS

¡No se deje engañar por la informalidad de SQLite! ¿Cuáles son las trampas de los tipos dinámicos? ¿Por qué ALTER TABLE está a medias? ¿Cómo construir una arquitectura de programación defensiva en Node.js para actualizaciones de esquema sin dolor?

Tue, 19 May 2026 18:10:00 +0800

¿Se imagina un contenedor de reciclaje en el que ha colocado claramente una etiqueta que dice "Solo botellas de plástico", pero cuando alguien tira un trozo de papel dentro, lo acepta silenciosamente sin una sola palabra de protesta?

Esta es la experiencia escalofriante que viven los desarrolladores cuando conocen el sistema de tipos de SQLite por primera vez.

Si está acostumbrado al estricto estilo de agente de aduanas de PostgreSQL (donde los tipos incorrectos se rechazan directamente), la informalidad de SQLite podría hacerle cuestionar su vida.

Aún más aterrador, cuando quiere modificar la estructura de una tabla, le dirá:

"La tabla no se puede modificar directamente. Por favor, construya una casa nueva, mude los muebles y luego vuele la casa vieja."

Bajo el capó, SQLite solo tiene 5 clases de almacenamiento

No importa qué nombres de tipo elegantes declare en CREATE TABLE (VARCHAR(255), BIGINT, DECIMAL), SQLite bajo el capó solo reconoce estas 5 clases de almacenamiento:

Clase de almacenamiento	Descripción
NULL	Valor nulo
INTEGER	Entero (ocupa automáticamente de 1 a 8 bytes según la magnitud)
REAL	Número de coma flotante (fijo de 8 bytes)
TEXT	Cadena de texto (codificación UTF-8 predeterminada)
BLOB	Objeto binario grande (almacenado exactamente como se ingresó)

Los tipos que establece en las columnas son simplemente "sugerencias" para SQLite, no "reglas obligatorias".

Esto se llama "Type Affinity" (Afinidad de tipos). SQLite intentará convertir sus datos al tipo sugerido, pero si no puede, simplemente meterá los datos originales de todos modos sin lanzar ningún error.

Puede declarar una columna age INTEGER en SQLite y luego insertar la cadena 'siempre dieciocho'; lo aceptará con gusto.

Tres trampas de tipos más fáciles en las que caer

Trampa 1: Sin Boolean nativo

SQLite not tiene tipo booleano. True y False solo pueden representarse mediante los enteros 1 y 0.

Cuando recupera datos de SQLite usando Node.js, obtendrá el número 1 o 0, no true o false.

Si realiza directamente una verificación como if (user.is_admin === true), nunca será verdadera.

Trampa 2: Sin tipo Date/Time

SQLite no tiene tipo de fecha/hora. Solo puede almacenar el tiempo como:

Método de almacenamiento	Ejemplo	Pros y contras
TEXT (cadena ISO-8601)	`'2026-05-19T18:00:00Z'`	Más recomendado, alta legibilidad, conversión perfecta al pasar a PostgreSQL en el futuro
INTEGER (Unix Timestamp)	`1747656000`	Huella pequeña, pero no legible por humanos

Nunca almacene fechas en formatos personalizados arbitrarios como 19/5/2026 6:00 PM, de lo contrario, la migración de datos en el futuro será un desastre.

Trampa 3: Insertar una cadena en una columna Integer no arrojará un error

En PostgreSQL, insertar una cadena en una columna INTEGER arroja un error de inmediato. But SQLite solo intentará convertirla silenciosamente, y si falla, la aceptará tal como está.

Esto significa que datos sucios podrían colarse silenciosamente en su base de datos hasta que un día su programa falle debido a la recepción de un tipo inesperado, solo entonces descubrirá el problema.

Programación defensiva: Tratar una base de datos informal con una actitud estricta

Frente a la informalidad de SQLite, debe construir mecanismos de defensa estrictos en el desarrollo con Node.js:

Nivel de defensa	Herramienta	Rol
Guardia en tiempo de compilación	TypeScript	Capturar tipos incorrectos en la etapa de escritura del código
Validación de entrada de API	Zod	Validar los datos entrantes estrictamente (asegurar que age sea siempre un número)
Conversión de tipos implícita	Prisma / Drizzle ORM	Manejar automáticamente las diferencias de tipos entre SQLite y PostgreSQL

Mover al "guardián de la validación de datos" desde la capa de la base de datos a la capa de la aplicación Node.js es una estrategia clave para aprovechar la velocidad de desarrollo de SQLite y al mismo tiempo garantizar la escalabilidad futura.

Al usar un ORM, siempre que declare type: 'boolean' en su código, el ORM lo convierte automáticamente a 1/0 al guardar en SQLite, y lo vuelve a convertir a true/false al leer, ocultando perfectamente las diferencias de tipos subyacentes.

ALTER TABLE está a medias: Qué se puede y qué no se puede modificar

El soporte de SQLite para modificar estructuras de tablas es muy limitado:

Operasi	Didukung
Agregar columna (`ADD COLUMN`)	Sí
Renombrar columna (`RENAME COLUMN`)	Sí
Eliminar columna (`DROP COLUMN`)	Sí (en versiones más nuevas)
Renombrar tabla (`RENAME TO`)	Sí
Cambiar tipo de columna	No
Agregar/eliminar restricciones `UNIQUE`, `NOT NULL`	No
Modificar clave primaria	No
Modificar clave foránea	No

Una vez que necesite realizar cualquiera de las modificaciones "no soportadas", SQLite requiere que ejecute la estrategia de "recrear y mover".

Los cuatro pasos para recrear y mover: La forma de actualizar tablas de SQLite

Dado que no se puede modificar directamente, la práctica estándar recomendada por los documentos oficiales es construir una casa nueva, mudar los muebles, volar la casa vieja y colocar la placa nueva:

Paso	Acción	Descripción
1	Crear tabla nueva	`CREATE TABLE users_new (...)` usando la estructura correcta
2	Copiar datos	`INSERT INTO users_new SELECT ... FROM users`
3	Eliminar tabla vieja	`DROP TABLE users`
4	Renombrar tabla	`ALTER TABLE users_new RENAME TO users`

Estos cuatro pasos deben ejecutarse de un solo tirón; cualquier corte de energía o caída de la aplicación a mitad del camino resultará en la pérdida de datos.

Garantizar que las actualizaciones no pierdan datos: Dos líneas de defensa de seguridad

Línea de defensa 1: Defensa física, copiar el archivo directamente

SQLite es esencialmente solo un archivo. Antes de ejecutar cualquier cambio de esquema, simplemente haga una copia del archivo .db como respaldo.

const fs = require('fs');
fs.copyFileSync('my_project.db', 'my_project_backup.db');

Si las cosas salen mal, reemplazar el archivo restaura todo en un instante. Esta es una ventaja que otras bases de datos grandes no pueden ofrecer.

Línea de defensa 2: Contenedor de Transaction, la máquina del tiempo de la base de datos

Envuelva todos los pasos de migración dentro de una sola Transaction; si algún paso falla, todo el proceso se revertirá automáticamente (Rollback) como si nunca hubiera pasado nada.

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

const migrateData = db.transaction(() => {
  db.prepare(`
    CREATE TABLE users_new (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      name TEXT NOT NULL,
      age INTEGER NOT NULL DEFAULT 18
    )
  `).run();

  db.prepare(`
    INSERT INTO users_new (id, name, age)
    SELECT id, name, COALESCE(age, 18) FROM users
  `).run();

  db.prepare('DROP TABLE users').run();
  db.prepare('ALTER TABLE users_new RENAME TO users').run();
});

try {
  migrateData();
  console.log('Tabla actualizada con éxito');
} catch (error) {
  console.error('La actualización falló, datos restaurados de forma segura:', error.message);
}

"Archivo de respaldo + Vinculación de Transaction" es el airbag de la migración de su base de datos.

Controle la informalidad de SQLite con una actitud estricta

Domine la informalidad de SQLite con una arquitectura estricta en la capa de aplicación para disfrutar de su velocidad de desarrollo ultrarrápida y evitar deudas técnicas futuras.

El sistema de tipos de SQLite es muy informal, y ALTER TABLE tiene muchas limitaciones.

Sin embargo, siempre que realice comprobación de tipos con TypeScript + validación con Zod + abstracción con ORM en el lado de Node.js, combinado con la estrategia de seguridad de respaldo físico + Transaction, puede disfrutar con seguridad de la eficiencia de desarrollo que ofrece SQLite mientras pavimenta el camino para migrar a PostgreSQL en el futuro.

Reference

¡No uses PostgreSQL para todo! ¿Cuáles son las ventajas de la arquitectura embebida y la configuración cero de SQLite? ¿Dónde están los límites de SQLite? ¿Cuándo deberías elegir SQLite y cuándo PostgreSQL?

Tue, 19 May 2026 18:00:00 +0800

¿Alguna vez has pensado en el hecho de que el navegador que abres todos los días, el software de comunicación en tu teléfono e incluso la herramienta de notas en tu escritorio ocultan la misma base de datos ligera?

No requiere que instales ningún software de servidor, no necesita configuraciones de cuenta o contraseña, y ni siquiera necesita una conexión a Internet. Es simplemente un archivo, que descansa silenciosamente en tu disco duro, listo para servirte en cualquier momento.

Esta existencia discreta es SQLite.

¿Qué es SQLite? La base de datos más implementada del mundo

SQLite es un motor de base de datos relacional embebido escrito en C.

No tiene un proceso de servidor independiente, sino que está embebido directamente en tu aplicación para ejecutarse.

Esto es completamente diferente de PostgreSQL o MySQL con los que estás familiarizado. Las bases de datos tradicionales son servidores independientes que se ejecutan por separado, y tu programa debe “comunicarse” con ellos a través de un protocolo de red (TCP/IP).

Pero SQLite es diferente; es simplemente un bloque de código que se ejecuta directamente dentro de tu aplicación, leyendo y escribiendo ese archivo .db en tu disco duro.

Dimensión de comparación	SQLite (Embebido)	PostgreSQL (Cliente-Servidor)
Modo de operación	Embebido directamente en la aplicación, sin servidor independiente	Proceso de servidor independiente, a través de conexión de red
Configuración	Configuración cero, sin instalación, sin credenciales	Requiere instalación, configuración de cuenta/contraseña y firewall
Almacenamiento de datos	Archivo único multiplataforma	Múltiples archivos bajo el directorio del servidor
Método de respaldo	Copiar directamente ese archivo	Requiere herramientas dedicadas como pg_dump

Es precisamente debido a esta característica de “conectar y usar” que SQLite se ha convertido en el motor de base de datos más implementado del mundo.

Desde los sistemas operativos Android e iOS, los navegadores Chrome y Firefox, hasta Adobe Lightroom, WhatsApp e incluso el sistema de vuelo del Airbus A350, está en todas partes.

Uso de SQLite en Node.js

Si eres desarrollador de Node.js, usar SQLite es extremadamente simple. No necesitas instalar ningún software de servidor de base de datos en tu computadora, solo necesitas instalar un paquete npm para comenzar.

Las opciones más utilizadas en la industria hoy en día:

Nombre del paquete	Características	Escenario recomendado
`sqlite3`	El más establecido, admite APIs asíncronas	Cuando se necesita manejar muchas tareas asíncronas concurrentemente
`better-sqlite3`	Rendimiento excelente, diseño de API intuitivo, extremadamente rápido	Recomendación principal, para eficiencia de desarrollo y velocidad de ejecución

Crear una base de datos y consultarla con better-sqlite3 toma 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 }

Si el archivo no existe, better-sqlite3 lo creará automáticamente para ti.

SQLite admite una sintaxis SQL más potente de lo que crees

Muchas personas piensan que SQLite es muy básico, pero admite la gran mayoría de la sintaxis SQL estándar, incluidas muchas características avanzadas:

Categoría de sintaxis	Elementos admitidos
Operaciones básicas	`SELECT`, `INSERT`, `UPDATE`, `DELETE`
Definición de datos	`CREATE TABLE`, `CREATE INDEX`, `CREATE VIEW`
Consultas avanzadas	`WITH` (CTEs recursivas), Funciones de ventana (Window Functions)
Manejo de conflictos	`UPSERT` (`INSERT ... ON CONFLICT DO UPDATE`)
Procesamiento de JSON	Funciones integradas como `json_extract`, `json_array`, `json_object`, etc.
Control de transacciones	`BEGIN`, `COMMIT`, `ROLLBACK`, `SAVEPOINT`
Consultas de unión	`INNER JOIN`, `LEFT JOIN`, `RIGHT JOIN` y `FULL OUTER JOIN`

La filosofía central de SQLite es “pequeño y hermoso”, admitiendo la mayoría de las capacidades SQL que necesitas a diario mientras se mantiene extremadamente ligero.

¿Dónde están los límites de SQLite?

La ligereza tiene un precio. Si se compara a SQLite con una tienda de barrio hipster con una sola caja de pago, entonces PostgreSQL es un Costco equipado con 50 cajas registradoras.

1. Atasco de tráfico de escritura

Cuando SQLite escribe datos, bloquea todo el archivo de la base de datos.

Imagina un restaurante con un solo baño: 100 personas pueden mirar el menú afuera (leer) al mismo tiempo, pero mientras 1 persona entra y cierra la puerta con llave (escribir), todos los demás solo pueden hacer fila y esperar.

Aunque activar el modo WAL (Write-Ahead Logging) puede mejorar el rendimiento de lectura/escritura concurrente, fundamentalmente sigue sin poder realizar escrituras concurrentes multiproceso en diferentes filas de datos.

2. No se puede distribuir en múltiples servidores

La esencia de SQLite es un archivo físico. Si tu sistema se despliega en múltiples servidores (escalado horizontal), estos servidores no pueden compartir de forma segura el mismo archivo.

3. Falta de gestión de permisos detallada

SQLite no tiene el concepto de “cuentas de usuario”. Cualquiera que pueda leer ese archivo .db a nivel del sistema operativo puede ver y modificar todos los datos.

Para sistemas de negocios que requieren auditorías estrictas de datos personales, esto es inaceptable.

SQLite vs. PostgreSQL: Decisiones de selección de tecnología

Las herramientas no son buenas ni malas, solo adecuadas o no. Aquí hay una lista de verificación definitiva para ayudarte a tomar decisiones:

Pregunta	Respuesta “Sí” → Elige SQLite	Respuesta “No” → Elige PostgreSQL
¿Hay solo un servidor backend, o se ejecuta completamente de forma local?	Sí	No (requiere escalado horizontal, múltiples máquinas)
¿El comportamiento del sistema está dominado por la lectura, sin escrituras concurrentes de alta frecuencia?	Sí	No (los usuarios competirán por escribir concurrentemente)
¿No necesitas permisos de cuenta de base de datos detallados o indexación avanzada?	Sí	No (depende en gran medida de características avanzadas)

Comparaciones de escenarios más específicos:

Escenario	Selección recomendada	Razón
Software de escritorio, Aplicaciones móviles, Dispositivos IoT	SQLite	Los datos viajan con el dispositivo, sin instalación
Blogs personales, Sitios web de exhibición	SQLite	Mucha lectura, poca escritura, ahorra costos de mantenimiento de servidor
Desarrollo rápido de prototipos, Demos	SQLite	Simplemente crea un archivo para comenzar
Foros comunitarios, Plataformas de comercio electrónico	PostgreSQL	Alta concurrencia de escritura, requiere bloqueo a nivel de fila
Despliegue distribuido en múltiples servidores	PostgreSQL	Necesita compartir la fuente de datos entre diferentes máquinas
Sistemas sensibles como médicos o financieros	PostgreSQL	Requiere un control de permisos estricto basado en roles

¿Es tu base de datos una nota de bolsillo o una centralita telefónica central?

Si los datos son “monomáquina, estáticos, de un solo propietario”, elige SQLite para disfrutar de una ligereza y libertad extremas;

Si los datos son “en la nube, dinámicos, altamente interactivos”, deja que PostgreSQL se haga cargo.

La filosofía central de SQLite es “un componente interno de la aplicación”, mientras que PostgreSQL se posiciona como “un centro independiente de la arquitectura del sistema”.

La próxima vez que tomes una decisión de arquitectura, no te apresures a sacar PostgreSQL. Pregúntate primero:

"¿Es mi base de datos una nota de bolsillo o una centralita telefónica central?"

Una vez que la respuesta esté clara, la elección naturalmente se vuelve obvia.