SQLite debería tener ediciones (al estilo Rust)

Artículo original ↗ Discusión en Hacker News ↗

El compromiso de larga data de SQLite con la compatibilidad hacia atrás choca con las expectativas modernas de valores predeterminados más seguros, lo que impulsa llamadas a un mecanismo de “edición” al estilo Rust que permita a las bases de datos nuevas optar por un comportamiento más estricto sin romper las antiguas. Los comentaristas debaten si un único interruptor tipo `PRAGMA edition=2026` para cosas como aplicar claves foráneas, tipado estricto, `busy_timeout` y modo WAL mejoraría de verdad la fiabilidad o solo ocultaría compensaciones de configuración importantes, especialmente dado el papel de SQLite como formato portátil en disco. Otros sostienen que las bibliotecas wrapper, los flags de compilación o incluso bases de datos embebidas alternativas (como DuckDB o Firebird) pueden ser mejores formas de obtener garantías más fuertes preservando al mismo tiempo el minimalismo y el tamaño reducido de SQLite.

Concepto y objetivos de las ediciones

  • A muchos comentaristas les gusta la idea de una pragma de “edición” o “nivel de compatibilidad” que agrupe un conjunto de valores predeterminados modernos (p. ej., tipado más estricto, aplicación de FKs, busy_timeout, WAL) sin romper el código antiguo.
  • Las ediciones se ven como una forma opcional de ir más allá de valores predeterminados de hace 20 años, preservando a la vez la promesa de compatibilidad hacia atrás de SQLite.
  • Se hacen comparaciones con las ediciones de Rust, los “epochs/profiles” de C++, las políticas de CMake, compatibility_level de Postfix y use strict de JS.

Compatibilidad hacia atrás y portabilidad

  • SQLite es un contenedor de datos que se mueve con frecuencia entre máquinas y herramientas; los binarios antiguos de /usr/bin/sqlite3 a menudo leen archivos creados por versiones embebidas más nuevas.
  • Los críticos temen que las ediciones puedan:
    • Exigir entender tanto las pragmas subyacentes como los mapeos de las ediciones.
    • Bloquear versiones intermedias de SQLite si la edición N implica funciones añadidas más tarde.
    • Complicar el manejo de datos existentes cuando se habilitan semánticas más estrictas.
  • Los defensores responden que estos son en gran medida los mismos problemas que existen hoy con pragmas individuales y proponen:
    • Hacer que las ediciones sean puramente macros a nivel de conexión (no almacenadas en el archivo).
    • Mantener reglas estrictas de un solo sentido y metadatos autodescriptivos.

Valores predeterminados: FKs, tipado, busy_timeout, WAL

  • Muchos coinciden en que los valores predeterminados actuales (sin aplicación de FK, tipado laxo, sin busy_timeout, journal de rollback) son malos para el uso típico de “base de datos de aplicación” y se sobreescriben con frecuencia.
  • Otros defienden el statu quo:
    • Los entornos embebidos/de pocos recursos pueden preferir minimalismo y tipado laxo.
    • busy_timeout es intrínsecamente específico de la aplicación; elegir 5 s frente a 1 s o 60 s es arbitrario.
    • WAL es un formato diferente, no universalmente soportado, y se considera más arriesgado por corrupción.

Tipado, tablas STRICT y calidad de datos

  • Varios comentaristas consideran que el sistema de tipos de SQLite es “peligroso” y preferirían que el tipado estricto fuera el valor predeterminado.
  • Otros sostienen que el tipado laxo es inestimable para ingerir CSV o datos heredados desordenados, donde son comunes fechas, números, etc. inválidos.
  • Las tablas STRICT se ven como un paso útil, pero no como una solución completa de validación; la validación seria a menudo sigue perteneciendo a una capa superior.

Alcance de SQLite y alternativas

  • Hay una fuerte oposición a convertir SQLite en un sistema cliente-servidor completo y altamente concurrente; algunos dicen “usa Postgres” u otros motores embebidos (DuckDB, Firebird) si necesitas eso.
  • Contrapunto: incluso una base de datos local de aplicación debería tener valores predeterminados más seguros; las ediciones o conjuntos de funciones podrían ofrecer esto sin cambiar el comportamiento heredado.

Preocupaciones de implementación y ecosistema

  • Las preocupaciones incluyen el aumento de código por cada edición añadida, el crecimiento de la superficie de pruebas y la posible confusión (“edición 2026” oculta lo que realmente está habilitado).
  • Mitigaciones sugeridas: implementar las ediciones como pequeñas macros sobre pragmas existentes; quizá permitir solo un conjunto limitado, o conjuntos de funciones en lugar de ediciones basadas en años.
  • Algunos ecosistemas de ORM y wrappers van retrasados respecto a funciones más nuevas de SQLite (p. ej., STRICT), lo que reduce el beneficio práctico hasta que las herramientas se pongan al día.