- Algunas desventajas sorprendentes que descubrí después de usar SQLite durante unos días
- No se admite
ALTER COLUMN. La recomendación oficial para modificar una columna: "crear una tabla nueva"
- No se admite
DROP CONSTRAINT. La recomendación oficial para eliminar una restricción: "crear una tabla nueva"
- SQLite no tiene tipos de datos en las columnas. Los tipos de datos (solo hay 5) existen únicamente en los valores, así que cualquier cosa puede entrar en cualquier lugar
- Si pides una columna de un tipo no admitido o inexistente, realiza una operación incorrecta sin advertencia ni error. Al crear un esquema como
CREATE TABLE my_table (id bigserial, messages jsonb[]), parecía que funcionaba, así que durante el primer día pensé por error que SQLite admitía serial y arreglos
- Puedes usar
CREATE TABLE my_table (...) STRICT para permitir solo uno de los 5 tipos admitidos: integer, real, text, blob, any
- Recientemente ha habido mucho interés por el nuevo soporte de
jsonb en SQLite. A diferencia de Postgres, jsonb en realidad no es un tipo de dato, sino un formato de entrada y salida para las funciones integradas jsonb*. Cuando se almacena de forma persistente, es uno de los 5 tipos básicos: blob
- También faltan otros tipos muy importantes, como
timestamptz. Si quieres fecha/hora, debes guardarla como un Unix timestamp integer o como una string en formato ISO8601, y se proporcionan varias funciones integradas para trabajar con eso
- SQLite tiene capacidades impresionantes relacionadas con streaming que me gustaría probar, pero la experiencia inicial de DX sin duda fue un poco incómoda
- A veces me pregunto de qué narrativa estoy demasiado convencido. Por ejemplo, ¿Postgres realmente es la mejor base de datos del mundo? Esta experiencia definitivamente reforzó mi convicción. Sí, Postgres es la mejor
6 comentarios
Parece que lo que quieren no es SQLite, sino SQLHeavy.
Hay todo tipo de bases de datos. Me hizo pensar que SQLite se mantiene con su propia filosofía.
¿Por qué intentaron usar SQLite como si fuera Postgres?
Se siente como cuando alguien que usa Linux por primera vez dice: “Ni siquiera funciona bien Hancom Office y tampoco corren los juegos que yo juego. ¡Definitivamente Windows sí es un sistema operativo!”
¿No será un poco exagerado el hype sobre sqlite que aparece en Hacker News? Desde 2022 han aparecido muchos posts en Hacker News afirmando que sqlite puede reemplazar a un RDBMS operado por separado.
1: https://news.ycombinator.com/item?id=31318708
2. https://news.ycombinator.com/item?id=31152490
3. https://news.ycombinator.com/item?id=34812527
4. https://news.ycombinator.com/item?id=36208568
Además: https://hn.algolia.com/?dateEnd=1720854657&dateRange=custom&da…
Creo que SQLite puede ser una alternativa bastante atractiva cuando usar una familia de bases de datos como Postgres o MySQL se siente como un exceso.
Por ejemplo, en el caso de servicios pequeños, el costo de una DB administrada a veces termina siendo desproporcionadamente alto, y operarla uno mismo también puede ser una carga.
En cambio, en el caso de SQLite, se dice que hasta cierto nivel de escala no le falta rendimiento, y sobre todo, si usas herramientas como Litestream, la carga operativa es casi nula, así que me parece que tiene sus ventajas.
Sin llegar siquiera a las funciones de replicación, SQLite es muy bueno porque también es fácil de respaldar y solo hay que administrar el estado del daemon del servicio, pero para integrarlo con JPA hay que hacer varias cosas, así que vi que no podía usarlo en proyectos que luego habría que entregar a otra persona. Y si, como en el texto original, existe la intención de manejar el esquema de datos de forma un poco más estricta, entonces tampoco encaja para ese uso.
Se me quedó a medias el comentario anterior, pero lo que quería decir es que los rumores infundados sobre SQLite crean la ilusión de que SQLite sirve para todo.