¿SQLite o Postgres, disco local o S3?

PrintStash usa SQLite por defecto para los metadatos y disco local para los archivos gestionados. Postgres y el almacenamiento de objetos compatible con S3 son opcionales. Casi todas las instalaciones domésticas deberían empezar con los valores por defecto y cambiar una sola capa cuando haya un motivo claro.

Usa SQLite en un servidor único normal

PrintStash suele ser una aplicación de poca concurrencia: unas pocas personas navegan por la biblioteca mientras las importaciones, los escaneos y las actualizaciones de las impresoras escriben en segundo plano. SQLite encaja con esa forma y mantiene la base de datos en un solo volumen persistente.

También reduce el número de servicios que tienes que vigilar. Una copia de seguridad completa de PrintStash captura una copia consistente de la base de datos SQLite junto con los blobs gestionados y las miniaturas.

Elige SQLite cuando:

• una sola instancia de la API de PrintStash sea la dueña de la base de datos;
• la biblioteca sirva a una casa o a un taller pequeño;
• una copia de seguridad y una recuperación sencillas importen más que encajar en una plataforma de bases de datos que ya tienes.

Deja el volumen de la base de datos en almacenamiento local fiable. No pongas un archivo SQLite en uso sobre un montaje SMB inestable.

Usa Postgres cuando resuelva un problema de operación

Postgres tiene sentido si ya lo gestionas, si quieres monitorización y herramientas de copia de seguridad a nivel de base de datos, o si esperas más escrituras concurrentes de las que produce una instalación doméstica. PrintStash sigue admitiendo un solo proceso de API por bóveda, sea cual sea la base de datos, y el arranque rechaza un segundo proceso.

Los dos motores exponen las mismas funciones de la aplicación. Elige Postgres por sus propiedades de operación, no por un comportamiento distinto de PrintStash.

Arranca el perfil incluido con:

docker compose --profile postgres up -d

Repasa las variables de entorno actuales y el plan de copias de seguridad antes de mover una instalación que ya existe.

Deja los archivos en disco local salvo que el almacenamiento de objetos te ayude

El almacenamiento local es el backend más sencillo para la bóveda gestionada. Las subidas, las previsualizaciones y las descargas se quedan cerca de la API, y las herramientas de copia de seguridad del host entienden los volúmenes.

El almacenamiento compatible con S3 sirve cuando los blobs gestionados deben vivir aparte del host de Docker, o cuando tu plataforma ya ofrece un almacén de objetos. PrintStash admite servicios como S3, R2 y MinIO con los mismos ajustes de backend. Las descargas usan URL prefirmadas de vida corta en lugar de pasar cada blob por la API.

El almacenamiento de objetos añade credenciales, política de bucket, dependencia de red y coste de proveedor. Úsalo cuando esos costes resuelvan un problema concreto de almacenamiento o de alojamiento.

Los volúmenes compartidos son otra decisión aparte. Permiten que PrintStash indexe en su sitio una carpeta local o de NAS que ya existe. Esos archivos de origen no son blobs de la bóveda gestionada y no se copian en una copia de seguridad completa de PrintStash.

Separa el almacenamiento en uso del almacenamiento de copias

El backend de almacenamiento de la bóveda y el espejo de copias de seguridad usan ajustes distintos. Una bóveda en disco local puede replicar los archivos de copia de seguridad a un bucket compatible con S3, que a menudo es más útil que mover la biblioteca en uso al almacenamiento de objetos.

Las copias de seguridad integradas se crean a demanda en las instalaciones con SQLite. Si quieres archivos nocturnos, llama a la API de copia de seguridad desde cron, systemd u otro planificador. Las instalaciones con PostgreSQL necesitan pg_dump y un procedimiento de restauración gestionado por quien opera el sistema. Prueba una restauración en un stack aparte y haz copia de las carpetas de origen de los volúmenes compartidos con las herramientas habituales de tu NAS.

Las migraciones ocurren al arrancar los contenedores

Las imágenes actuales ejecutan las migraciones de la base de datos a través del entrypoint del contenedor. El mismo proceso vale para SQLite y para Postgres. Así que una actualización normal es:

docker compose pull
docker compose up -d

Haz antes una copia de seguridad completa, lee las notas de la versión y revisa los logs de la API después del arranque. La guía de actualización incluye pasos de recuperación para instalaciones antiguas con un historial de migraciones poco habitual.

Para la mayoría, SQLite con disco local y una copia de seguridad fuera del host es el punto de partida práctico. Añade Postgres o S3 cuando estés listo para operar la dependencia extra.