Por qué SQLite está en todas partes: la base de datos embebida que triunfa

Qué es SQLite (y por qué la gente sigue eligiéndola)

SQLite es un motor de base de datos pequeño empaquetado como una biblioteca que tu aplicacion enlaza—como una funcionalidad que incluyes, no como un servicio que ejecutas. En lugar de hablar por la red con una maquina de base de datos separada, tu app lee y escribe en un solo archivo de base de datos (a menudo algo como app.db) en disco.

Esa idea de “es solo un archivo” es parte importante del atractivo. El archivo de base de datos contiene tablas, indices y datos, y SQLite se encarga de las partes dificiles—consultas, restricciones y transacciones ACID—detras de escena.

Embebida vs “Servidor de base de datos”

Con una base de datos cliente-servidor (piensa en PostgreSQL o MySQL), normalmente:

• instalas y ejecutas un servidor de base de datos
• configuras usuarios, puertos, backups, monitorizacion
• te conectas desde tu aplicacion por TCP

Con SQLite, la base de datos se ejecuta dentro del proceso de tu aplicacion. No hay un servidor separado que instalar, arrancar o mantener. Tu app llama a la API de SQLite, y SQLite lee/escribe el archivo local directamente.

La gente suele describir SQLite como “sin servidor”. Eso no significa que viva en la nube sin servidores—significa que tú no gestionas un proceso de servidor de base de datos separado.

Probablemente has usado SQLite sin darte cuenta

SQLite aparece de forma silenciosa en mucho software cotidiano porque es facil de distribuir y fiable:

• apps moviles que necesitan una base de datos local
• apps de escritorio que almacenan configuracion, caches o datos de usuario
• navegadores, apps de chat y herramientas que necesitan almacenamiento estructurado
• apps local-first que siguen funcionando sin conexion

Muchos productos eligen SQLite porque es un valor por defecto directo: rapido, estable y sin configuracion.

Un gran valor por defecto (con limites)

SQLite es una excelente eleccion para muchas apps de un solo usuario, dispositivos embebidos, prototipos que se convierten en productos reales y servicios con concurrencia de escritura moderada. Pero no es la respuesta a todos los problemas de escalado—sobre todo cuando muchas maquinas necesitan escribir en la misma base de datos al mismo tiempo.

La idea clave: SQLite no es “pequeña” en capacidad—es pequeña en carga operativa. Por eso la gente la sigue escogiendo.

Qué significan realmente “embebida” y “sin servidor”

SQLite se etiqueta con dos palabras que pueden sonar de moda: embebida y sin servidor. En SQLite, ambas tienen significados especificos y practicos.

“Embebida” = una biblioteca, no un servicio

SQLite no es algo que “ejecutes” en segundo plano como PostgreSQL o MySQL. Es una biblioteca de software que tu aplicacion enlaza y usa directamente.

Cuando tu app necesita leer o escribir, llama funciones de SQLite dentro del mismo proceso. No hay un demonio de base de datos separado que iniciar, monitorizar, parchear o reiniciar. Tu app y el motor de base de datos conviven.

“Sin servidor” (estilo SQLite) = sin proceso de servidor de base de datos separado

El “sin servidor” de SQLite no significa lo mismo que los “servicios serverless” que ofrecen los proveedores en la nube.

• Productos cloud serverless siguen teniendo servidores—simplemente no los gestionas. Te conectas por la red, pagas por capacidad/uso y las operaciones ocurren en infraestructuras que no controlas.
• SQLite sin servidor significa que simplemente no hay servidor de base de datos. La base de datos suele ser un archivo local, y tu app lo lee/escribe directamente.

Cómo hablan las apps con SQLite

Con bases de datos cliente-servidor, tu codigo envia SQL por TCP a otro proceso. Con SQLite, tu codigo emite SQL mediante llamadas a la biblioteca (a menudo via un binding de lenguaje), y SQLite lee/escribe el archivo en disco.

El resultado: sin salto de red, sin pool de conexiones que afinar y menos modos de fallo (como “no se puede conectar al host de BD”).

Qué significa esto para las operaciones

Para muchos productos, “embebida + sin servidor” se traduce en menos piezas en movimiento:

• Sin paso de instalacion de base de datos en maquinas de desarrollador
• Despliegues mas simples (especialmente para escritorio, movil y edge)
• Pruebas locales mas faciles y entornos mas reproducibles

Esa simplicidad es una gran razon por la que SQLite aparece en todas partes—incluso cuando los equipos podrian elegir algo mas pesado.

La ventaja de cero configuracion: envia un archivo, no un servicio

El beneficio mas subestimado de SQLite es tambien el mas simple: tu base de datos es un archivo que viaja con tu app. No hay un servidor separado que aprovisionar, ni puertos que abrir, ni cuentas de usuario que crear, ni lista de comprobacion de “¿esta la base de datos en marcha?” antes de que algo funcione.

Despliegues y actualizaciones mucho mas simples

Con una base de datos cliente-servidor, desplegar una app suele implicar infraestructura: una instancia de BD, migraciones, monitorizacion, credenciales y un plan de escalado. Con SQLite, normalmente empaquetas un archivo .db inicial (o lo creas en la primera ejecucion) y tu aplicacion lo lee y escribe directamente.

Las actualizaciones tambien pueden ser mas faciles. ¿Necesitas una nueva tabla o indice? Envia una actualizacion de la aplicacion que ejecute migraciones contra el archivo local. Para muchos productos, eso convierte un despliegue en varios pasos en un solo artefacto de lanzamiento.

Encaja perfecto en escritorio, movil y edge

Este modelo de “enviar un archivo” brilla cuando el entorno es restringido o distribuido:

• Apps de escritorio: instala una vez, funciona offline, almacena datos localmente con minima ceremonia.
• Apps moviles: patron demostrado para almacenamiento en el dispositivo cuando el acceso a red es intermitente.
• Dispositivos edge / quioscos / sistemas embebidos: menos piezas en movimiento significa menos puntos de fallo, especialmente donde la administracion remota es dificil.

Backups basados en archivo—pero aun requieren plan

Copiar un archivo de base de datos parece trivial, y puede serlo—si lo haces correctamente. No siempre puedes copiar de forma segura un archivo de base de datos en vivo con una copia de archivo naive mientras la app esta escribiendo. Usa los mecanismos de backup de SQLite (o asegura un snapshot consistente) y almacena backups en un lugar durable.

Menos trabajo de DBA dedicado

Como no hay un servidor que afinar y vigilar, muchos equipos evitan una parte de la carga operativa: parchear un servicio de BD, gestionar pools de conexion, rotar credenciales y mantener replicas sanas. Aun necesitas buen diseno de esquema y migraciones—pero la huella de “operaciones de base de datos” es menor.

Fiabilidad ante todo: transacciones e integridad de datos

La popularidad de SQLite no es solo por conveniencia. Una gran razon por la que la gente confia en ella es que prioriza la correccion por encima de funcionalidades llamativas. Para muchas apps, la caracteristica de BD mas importante es simple: no perder ni corromper datos.

ACID, explicado en palabras sencillas

SQLite soporta transacciones ACID, que es una forma compacta de decir “tus datos se mantienen en orden incluso cuando algo va mal”.

• Atomico: un cambio es todo o nada. Si una operacion incluye 5 actualizaciones y la app cae despues de 3, SQLite no te deja con un resultado a medias.
• Consistente: las reglas que esperas se mantienen. Si tu app espera que saldos no sean negativos, las transacciones ayudan a mantener las actualizaciones ordenadas.
• Aislado: operaciones multiples no se pisan entre si. Una accion no leera cambios a medias de otra.
• Durable: cuando SQLite indica que una transaccion se commitio, deberia seguir ahi tras un fallo o corte de energia.

Modos de journaling (a nivel alto)

SQLite consigue seguridad ante fallos usando un journal—una red de seguridad que registra lo que esta a punto de cambiar para poder recuperarse limpiamente.

Dos modos comunes que oiras:

• Rollback journal: el enfoque clasico. SQLite puede "deshacer" trabajo incompleto si algo interrumpe una escritura.
• WAL (Write-Ahead Logging): suele mejorar la concurrencia al separar lecturas de escrituras, y puede acelerar la recuperacion porque los cambios se anexan y luego se consolidan.

No necesitas conocer los detalles internos para beneficiarte: la idea es que SQLite esta diseñada para recuperarse de forma predecible.

Por qué esto importa mas que funciones extra

Muchas aplicaciones no necesitan clustering a medida ni tipos de datos exoticos. Necesitan registros exactos, actualizaciones seguras y la confianza de que un fallo no corrompera silenciosamente los datos de usuario. El enfoque de SQLite en la integridad es una razon mayor para su uso en productos donde "aburrido y correcto" vence a "impresionante y complejo".

Rendimiento: rapido porque esta cerca de tu codigo

SQLite a menudo se siente "instantanea" porque tu app habla con la BD en proceso. No hay un servidor separado que conectar, ni handshake TCP, ni latencia de red. Una consulta es solo una llamada a funcion que lee desde un archivo local (a menudo ayudado por la cache de paginas del SO), asi que el tiempo entre "ejecutar SQL" y "recibir filas" puede ser sorprendentemente corto.

Donde SQLite suele destacar

Para muchos productos, la carga de trabajo son mayormente lecturas con un flujo constante de escrituras: cargar estado de la app, buscar, filtrar, ordenar y unir tablas pequenas o medianas. SQLite es excelente en esto. Puede hacer busquedas indexadas eficientes, escaneos de rango rapidos y agregaciones rapidas cuando los datos caben comodamente en almacenamiento local.

Las cargas de escritura moderadas tambien encajan bien—piensa en preferencias de usuario, colas de sincronizacion en segundo plano, respuestas de API en cache, logs de eventos o una tienda local-first que fusiona cambios despues.

El cuello de botella principal: concurrencia de escrituras

El compromiso de SQLite es la concurrencia en escrituras. Soporta varios lectores, pero las escrituras requieren coordinacion para que la base de datos siga consistente. Bajo escrituras concurrentes intensas (muchos hilos/procesos intentando actualizar al mismo tiempo), puedes encontrar contencion de locks y ver reintentos o errores de "database is busy" a menos que afines el comportamiento y disenes los patrones de acceso.

Los fundamentos SQL siguen importando

SQLite no es "rapida por defecto" si las consultas estan mal diseñadas. Indices, clausulas WHERE selectivas, evitar escaneos completos de tabla innecesarios y mantener las transacciones correctamente acotadas marcan una gran diferencia. Tratalo como una base de datos real—porque lo es.

Portabilidad y el modelo de un solo archivo

La caracteristica mas distintiva de SQLite es tambien la mas simple: toda tu base de datos es un unico archivo (mas archivos secundarios opcionales como el WAL). Ese archivo contiene el esquema, datos, indices—todo lo que la app necesita.

Una base de datos que puedes llevar contigo

Porque es "solo un archivo", la portabilidad se convierte en una caracteristica por defecto. Puedes copiarlo, adjuntarlo a un informe de bug, compartirlo con un compañero (cuando corresponda) o moverlo entre maquinas sin configurar un servidor, usuarios o acceso en red.

SQLite corre en virtualmente todas las plataformas principales: Windows, macOS, Linux, iOS, Android y una larga lista de entornos embebidos. Ese soporte multiplataforma se combina con estabilidad a largo plazo: SQLite es famosa por ser conservadora con la compatibilidad hacia atras, asi que un archivo de base de datos creado hace años normalmente aun puede abrirse y leerse con versiones nuevas.

Pruebas portables y entornos reproducibles

El modelo de un solo archivo es tambien un superpoder para testing. ¿Quieres un conjunto de datos conocido para una suite de tests unitarios? Incluye un pequeño archivo SQLite (o generalo durante las pruebas), y cada desarrollador y job de CI empieza desde la misma base. ¿Necesitas reproducir un problema de un cliente? Pide el archivo DB (con el debido manejo de privacidad) y puedes reproducir el problema localmente—sin el misterio de "solo pasa en su servidor".

Nota practica: trata el archivo DB como datos de aplicacion

Esa portabilidad tiene doble filo: si el archivo se borra o se corrompe, tus datos se pierden. Trata la base de datos SQLite como cualquier activo importante de la app:

• guardala en el directorio de datos del SO apropiado para la app
• incluyela en backups donde corresponda
• protejela con permisos del sistema de ficheros y cifrado cuando sea necesario
• evita ubicaciones de "carpeta temporal" a menos que los datos sean verdaderamente desechables

Ecosistema y herramientas que facilitan adoptar SQLite

SQLite es facil de aprender en parte porque rara vez empiezas desde cero. Viene integrado en muchas plataformas, se incluye en runtimes de lenguaje comunes y tiene compatibilidad "aburrida" a traves de entornos—exactamente lo que quieres para una base de datos que embebes dentro de una app.

Integraciones que realmente usaras

La mayoria de stacks ya tienen un camino bien recorrido hacia SQLite:

• Lenguajes: Python (sqlite3 en la libreria estandar), Go (mattn/go-sqlite3), Java (drivers JDBC), .NET (Microsoft.Data.Sqlite), PHP (PDO SQLite), Node.js (better-sqlite3, sqlite3).
• Frameworks/ORMs: Rails (Active Record), Django, Laravel, SQLAlchemy, Prisma, Sequelize, Entity Framework.
• Movil y escritorio: iOS y macOS (SQLite disponible a nivel de sistema), Android (APIs de SQLite), ademas de wrappers como Room (Android), GRDB (Swift) y muchos plugins para React Native/Flutter.

Esa amplitud importa porque significa que tu equipo puede usar patrones familiares—migraciones, query builders, gestion de conexiones—sin inventar tuberias personalizadas.

Herramientas: desde "echar un vistazo al archivo" hasta flujos de trabajo reales

Las herramientas de SQLite son inusualmente accesibles. El CLI sqlite3 facilita inspeccionar tablas, ejecutar consultas, volcar datos o importar CSV. Para exploracion visual, visores de escritorio o basados en navegador (por ejemplo, SQLiteStudio o DB Browser for SQLite) ayudan a no especialistas a validar datos rapidamente.

En el lado de entrega, las herramientas de migracion mainstream suelen soportar SQLite: migraciones de Rails, Django, Flyway/Liquibase, Alembic y Prisma Migrate hacen cambios de esquema repetibles.

El bucle de retroalimentacion del "esta en todas partes"

Porque SQLite esta tan desplegada, los problemas tienden a estar bien entendidos: las librerias se prueban en produccion, los casos borde se documentan y los ejemplos de la comunidad abundan. Esa popularidad genera mas soporte, lo que facilita aun mas la adopcion.

Al elegir una libreria, prefiere drivers/adapteres mantenidos activamente para tu stack y revisa el comportamiento de concurrencia, el soporte del binding y como se manejan las migraciones. Una integracion bien soportada suele ser la diferencia entre un despliegue suave y un fin de semana de sorpresas.

Donde aparece SQLite: casos de uso reales

SQLite se entiende mejor cuando miras donde se usa realmente: lugares donde un servidor de base de datos completo añadiria coste, complejidad y modos de fallo.

Apps moviles y tablets

Muchas apps moviles necesitan un almacen local fiable para sesiones de usuario, contenido en cache, notas o colas de "elementos para subir mas tarde". SQLite encaja porque es un archivo unico con transacciones ACID, asi que tus datos sobreviven a caidas, apagados por bateria y conectividad inestable.

Esto es especialmente fuerte en apps offline-first y local-first: escribe cada cambio localmente y luego sincroniza en segundo plano cuando haya red. El beneficio no es solo soporte offline—es una UI rapida y comportamiento predecible porque lecturas y escrituras permanecen en el dispositivo.

Apps de escritorio e instaladores

El software de escritorio a menudo necesita una base de datos sin pedir al usuario que configure nada. Enviar un archivo SQLite unico (o crearlo en la primera ejecucion) mantiene la instalacion simple y hace los backups entendibles: copia un archivo.

Apps como herramientas de contabilidad, gestores de medios y sistemas CRM ligeros usan SQLite para tener los datos cerca de la app, lo que mejora el rendimiento y evita problemas de "¿esta corriendo el servidor de BD?".

Navegadores y herramientas cliente

SQLite aparece dentro de herramientas de desarrollo y aplicaciones que necesitan almacenamiento estructurado para historiales, indices y metadatos. Es popular aqui porque es estable, portable y no requiere un proceso separado.

Dispositivos embebidos y appliances

Routers, quioscos, terminales punto de venta y gateways IoT a menudo almacenan configuracion, logs y datasets pequenos localmente. La reducida huella y la portabilidad basada en archivos hacen a SQLite practica para desplegar y actualizar.

Flujos de trabajo de desarrolladores: dev local, tests, prototipos

Los desarrolladores usan SQLite para prototipos rapidos, bases de datos locales de desarrollo y fixtures de prueba. Es cero configuracion, facil de resetear y determinista—beneficios que se traducen en iteracion mas rapida y runs de CI mas fiables.

Este patron tambien es comun cuando se construye con Koder.ai: los equipos empiezan con SQLite para iteracion local rapida (o despliegue single-tenant), luego exportan el codigo generado y migran a PostgreSQL cuando el producto necesita escalado multi-escritor. Ese flujo de "empezar simple, migrar cuando sea necesario" mantiene la entrega temprana rapida sin encerrarte.

Cuando SQLite no es la mejor opcion

SQLite es un gran valor por defecto para almacenamiento local, pero no es la respuesta universal. La clave es juzgarla por tu carga de trabajo y necesidades operativas—no por el bombo.

Necesitas muchos usuarios escribiendo al mismo tiempo

SQLite maneja bien multiples lectores, pero las escrituras estan mas constreñidas porque los cambios finalmente deben serializarse para mantener el archivo consistente. Si tienes muchos usuarios o procesos intentando modificar datos concurrentemente—especialmente desde maquinas diferentes—una base de datos cliente-servidor (como PostgreSQL o MySQL) suele ser una mejor opcion.

Un signo comun es una app que "todo funciona en un portatil", pero bajo uso real ves timeouts, contencion de locks o colas alrededor de las escrituras.

Cargas de escritura intensas y escrituras paralelas

SQLite puede ser muy rapido, pero esta optimizado para otra forma de trabajo: muchas lecturas y una tasa moderada de escrituras. Si tu sistema hace inserciones/actualizaciones de alta frecuencia (ingestion de metricas, streams de eventos, colas de trabajo, logs de alto volumen) y espera muchos escritores paralelos, una BD servidor normalmente escala de forma mas predecible.

Esto no es solo cuestion de "velocidad". Tambien es sobre consistencia de latencia: una rafaga de escrituras puede bloquear a otros escritores y a veces a lectores, creando picos de latencia que son dificiles de explicar a los stakeholders.

Control de acceso centralizado, auditoria y acceso en red

Si necesitas una base de datos central compartida en red con permisos basados en roles, trazabilidad de cambios, backups centralizados y caracteristicas de gobernanza, SQLite probablemente no sea la herramienta adecuada. Puedes poner un archivo SQLite en un share de red, pero eso tiende a introducir problemas de fiabilidad y bloqueo.

Una BD servidor brilla cuando necesitas:

• Autenticacion/autorizacion centralizada
• Auditoria de quien cambio que y cuando
• Backups gestionados, replicacion y recuperacion punto en el tiempo
• Acceso remoto seguro para multiples servicios y equipos

Una forma practica de decidir

Hazte dos preguntas:

1. Como es la concurrencia en produccion (cuantos escritores, que tan rafagosa)?
2. Quien la operara (necesitas controles centralizados y acceso compartido)?

Si las respuestas honestas apuntan a “muchos escritores” y “gobernanza central”, elegir una base de datos cliente-servidor no es exagerado—suele ser el camino mas simple y seguro.

SQLite vs bases de datos cliente-servidor: comparacion practica

SQLite y bases como PostgreSQL o MySQL pueden almacenar tablas y ejecutar SQL, pero estan construidas para formas de problema diferentes.

Arquitectura: en-proceso y archivo vs servicio en red

SQLite corre dentro del proceso de tu aplicacion. Tu codigo llama a SQLite, y SQLite lee/escribe directamente un archivo local.

Una base de datos cliente-servidor corre como un servicio separado. Tu app se conecta por la red (incluso si la red es localhost), envia consultas y el servidor gestiona almacenamiento, concurrencia, usuarios y trabajo en segundo plano.

Esta diferencia explica la mayor parte de los trade-offs practicos.

Trade-offs operativos: simplicidad vs control central

Con SQLite, el despliegue puede ser tan simple como enviar un binario mas un archivo. Sin puertos, sin credenciales, sin upgrades de servidor—a menudo una gran ventaja para apps de escritorio, movil, edge y productos local-first.

Las BD cliente-servidor destacan cuando necesitas gestion centralizada: muchas apps y usuarios golpeando la misma BD, control de acceso fino, backups online, replicas de lectura y observabilidad madura.

Escalado: como crece cada una

SQLite tipicamente escala por:

• Escalado vertical: disco/CPU mas rapido, mejores consultas, caching
• Sharding natural: una base de datos por usuario, dispositivo, tenant o proyecto (patron comun)
• Graduacion: mover cargas compartidas y multi-escritor a una BD servidor cuando la coordinacion se vuelve cuello de botella

Las BD cliente-servidor escalan mas facil para cargas compartidas mediante maquinas mas grandes, replicacion, particionado y pooling.

Lista rápida de decision

Elige SQLite si quieres datos locales, operaciones minimas y que una unica instancia de la app sea la propietaria de las escrituras.

Elige una BD cliente-servidor si necesitas muchos escritores concurrentes, acceso remoto desde varios servicios, gobernanza central o alta disponibilidad integrada.

Si dudas, empieza con SQLite por velocidad de entrega y mantén una ruta clara de migracion (esquemas, migraciones, export/import) a PostgreSQL despues (/blog/migrating-from-sqlite).

Consejos para usar SQLite con seguridad en produccion

SQLite puede funcionar bien en produccion—pero tratalo como una base de datos real, no como un "archivo temporal que puedes copiar a lo bruto". Unos cuantos habitos marcan la diferencia entre operacion suave y caidas sorpresa.

Concurrencia: mantén transacciones cortas

SQLite soporta multiples lectores y (normalmente) un solo escritor a la vez. Eso esta bien para muchas apps siempre que lo diseñes apropiadamente.

Mantén las transacciones de escritura cortas y enfocadas: prepara el trabajo en tu app primero, luego abre una transaccion, escribe y commitea rapido. Evita transacciones de larga duracion que mantengan locks mientras esperas llamadas de red, input de usuario o bucles lentos. Si tienes jobs en segundo plano, encola escrituras para que no se acumulen y bloqueen peticiones interactivas.

Considera el modo WAL para mejor comportamiento lectura/escritura

Write-Ahead Logging (WAL) cambia como SQLite registra los cambios para que los lectores puedan seguir leyendo mientras hay un escritor activo. Para muchas apps—especialmente con muchas lecturas y escrituras ocasionales—WAL reduce la friccion de "database is locked" y mejora el throughput.

WAL no es magico: aun tienes un escritor, y debes tener en cuenta los archivos WAL adicionales en disco. Pero es una opcion comun y practica para despliegues en produccion.

Backups y migraciones: planificalos de todos modos

Aunque SQLite es un solo archivo, necesitas una estrategia de backup. No te bases en copiar el archivo al azar; coordina los backups para capturar un estado consistente (especialmente bajo carga).

Igualmente, gestiona cambios de esquema con migraciones. Versionalas, ejecútalas automaticamente durante el deploy y prueba las rutas de rollback/forward cuando sea posible.

Prueba como en produccion

Usa el mismo esquema, indices y ajustes criticos (como el modo de journal) en staging y pruebas automatizadas. Muchas "sorpresas" de SQLite aparecen solo cuando los tamanos de datos crecen o la concurrencia aumenta—asi que haz pruebas de carga con volúmenes y patrones de acceso realistas antes de lanzar.

Conclusión: por qué “embebida” suele ser una ventaja, no un limite

SQLite esta en todas partes porque hace que almacenar datos se sienta como usar una biblioteca, no como ejecutar infraestructura. Obtienes un motor SQL probado, transacciones ACID y herramientas maduras—sin aprovisionar un servidor de base de datos, gestionar usuarios ni vigilar una conexion de red.

Por qué la gente sigue eligiendo SQLite

En su mejor forma, SQLite es la opcion de "simplemente funciona":

• Cero configuracion: envia un unico archivo con tu app y empieza a leer/escribir de inmediato.
• Fiabilidad: las transacciones protegen tus datos aun cuando las apps fallan o los dispositivos pierden energia.
• Velocidad: los datos estan junto a tu codigo, asi que no hay ida y vuelta de red para la mayoria de consultas.
• Portabilidad: la base de datos es un archivo que puedes copiar, respaldar, sincronizar o incluir en pruebas.
• Ecosistema: drivers, migraciones, herramientas admin y patrones de despliegue son ampliamente conocidos.

La limitacion clave a recordar

SQLite no esta disenada para alta concurrencia de escrituras ni para acceso centralizado y multiusuario via red. Muchos lectores pueden consultar a la vez, pero escrituras concurrentes intensas (o muchos clientes compartiendo un archivo) son donde una BD cliente-servidor suele ser la opcion mas segura.

Un siguiente paso simple

Describe tu carga de trabajo—luego elige la herramienta mas simple que encaje. Si tu app es mayormente local, de un solo usuario o "local-first", SQLite suele ser perfecta.

Lista rapida

• ¿La BD vivira en el dispositivo / en la misma maquina que la app?
• ¿Las escrituras son relativamente pocas o faciles de serializar?
• ¿Necesitas operacion offline y despliegue simple?
• ¿Puedes respaldar / sincronizar un archivo unico de forma segura?
• ¿Requieres muchos escritores concurrentes o una BD central compartida para muchos usuarios?

Si respondiste “si” a las primeras cuatro y “no” a la ultima, SQLite es una opcion por defecto muy solida.