Sitios web de uso interno: ¿hay un caso convincente contra SQLite?

Muchos marcos web, como Flask o Django, usan SQLite como su base de datos predeterminada. SQLite es convincente porque está incluido en python, y la sobrecarga administrativa es bastante baja.

Sin embargo, la mayoría de los sitios de producción pública de alto tráfico terminan usando una base de datos más pesada: mySQL, Oracle o postgresql.

Las preguntas :

Asumir:

• El tráfico del sitio es moderado y se producirá acceso simultáneo de lectura / escritura a la base de datos
• Usaremos SQLAlchemy con bloqueos de escritura SQLite (aunque este comentario me pone un poco nervioso)
• La base de datos contendrá quizás 60,000 registros.
• Las estructuras de datos no requieren características avanzadas que se encuentran en bases de datos más pesadas

¿Existe algún caso convincente contra la concurrencia de SQLite para sitios web que sirven como herramientas corporativas internas de tráfico moderado? Si es así, ¿qué condiciones harán que SQLite tenga problemas de concurrencia?

Estoy buscando causas raíz específicas conocidas, en lugar de miedo general / señalar con el dedo sin fundamento.

Recomiendo leer la respuesta oficial a su pregunta, Usos apropiados para SQLite . Específicamente, "Situaciones en las que otro RDBMS puede funcionar mejor" advierte que SQLite no admite la escritura concurrente:

SQLite admite una cantidad ilimitada de lectores simultáneos, pero solo permitirá un escritor en cualquier momento. Para muchas situaciones, esto no es un problema. Cada aplicación hace que su base de datos funcione rápidamente y avanza, y ningún bloqueo dura más de unas pocas docenas de milisegundos. Pero hay algunas aplicaciones que requieren más concurrencia, y esas aplicaciones pueden necesitar buscar una solución diferente.

Desde una perspectiva de adecuación, tiendo a ver SQLite como un formato de archivo muy sofisticado que admite consultas SQL. Tendería a evitar SQLite si quisiera separar mi base de datos de mi aplicación web, ya que no está optimizada para este caso. En resumen, SQLite es insuficientemente escalable para su uso en algunos escenarios, por lo que las personas que ejecutan sitios web que esperan algún día ser populares podrían comenzar mejor con algo escalable, en lugar de ir con SQLite y luego verse obligados a cambiar.

Dicho todo esto, SQLite probablemente esté bien para la mayoría de los sitios web internos; Por lo general, los sitios web internos no requieren el mismo nivel de concurrencia y escalabilidad.

Al ponerme el sombrero de Director de TI, veo algunos no-gos aquí:

• Riesgo de corrupción de datos. Quizás más percibido que real, pero al final del día, este es un DB de tipo de archivo no transaccional que no tiene mucho o ningún recurso para malas escrituras además de preguntar si tiene una copia de seguridad reciente. Hablando de que . . .
• ¿Cómo respaldo esto? En cierto modo, sé que tengo una buena copia. Preferiblemente sin desconectar la aplicación.
• ¿Cómo puedo asegurar el acceso a la base de datos? Mi comprensión general es que SQL Lite no tiene ninguno fuera del acceso al sistema de archivos, que es un comienzo decente, pero no el principio absoluto. Especialmente para aplicaciones web donde es posible que desee más permisos graduados que DBA o nada.

Desde el punto de vista del desarrollador, creo que es importante saber por qué SqlLite es el predeterminado: es porque es fácil y se muestra bien. Si está "vendiendo" una plataforma a nuevos desarrolladores, es clave poder iniciar una aplicación web que funcione con un mínimo de alboroto. Y tener que ponerse de pie y configurar adecuadamente un servidor de base de datos sería un gran obstáculo para evitar.