PocketBase 0.39: formularios, archivos y backup
PocketBase 0.39.10 sirve para formularios internos con SQLite, API, usuarios y archivos. La decisión pasa por permisos, respaldo y salida probada.
Diez usuarios de un SaaS a USD 12 mensuales ya pagan un VPS chico, aunque ese ahorro desaparece si nadie prueba la restauración. PocketBase 0.39.10 reúne base SQLite, API, autenticación, archivos y panel de administración en un binario. Para una pyme con carga de órdenes, reclamos o fotos, esta guía muestra dónde vive el dato, quién lo puede borrar y qué prueba exige producción.
Dónde aparece el formulario que crece sin permiso
El problema operativo aparece cuando un formulario chico empieza a guardar decisiones reales. Primero registra reclamos, después adjunta fotos, luego suma estados y al final contiene datos que compras, soporte y gerencia usan todos los días. El antagonista es la planilla convertida en aplicación sin dueño: todos cargan filas y nadie sabe qué permiso protege cada columna. La cifra que corrige la conversación viene de GitHub. El repositorio pocketbase/pocketbase registraba 60.590 estrellas, 3.629 forks y licencia MIT al momento de esta corrida. La release v0.39.10 fue publicada el 30 de julio de 2026. Ese tamaño de comunidad ayuda, aunque la decisión técnica sigue siendo local: qué datos admite el flujo y cómo vuelve después de una caída. La documentación de collections explica que una colección se administra desde el panel, APIs o migraciones, y que el campo de archivo guarda el nombre en la base mientras el archivo queda en disco local o S3 según la configuración. El dato de contexto viene de Stack Overflow 2025: SQL aparece con 61,9% entre desarrolladores profesionales. Para una organización chica, esa familiaridad reduce la distancia entre formulario y auditoría.
Cómo funciona por dentro
El flujo arranca con una colección de negocio: reclamos, pedidos internos, órdenes de compra, inspecciones o socios. PocketBase crea la estructura, expone APIs y guarda registros en SQLite dentro de su directorio de datos. La aplicación o el panel reciben campos, usuarios y archivos. Las reglas de acceso deciden quién lista, crea, edita, borra o descarga. 1. Administración define una colección con campos, estados y responsables. 2. PocketBase guarda registros estructurados en SQLite y expone una API. 3. El usuario carga datos y adjuntos desde un formulario web. 4. Los archivos quedan en pb_data/storage o en S3 compatible. 5. Las reglas de autenticación filtran lectura, creación, edición y borrado. 6. Un tablero o exportación CSV muestra pendientes, cerrados y cambios. 7. El backup copia pb_data, configuración y archivos; una restauración abre un registro real. La guía de archivos marca un punto práctico: por defecto los uploads viven en pb_data/storage; también se puede usar S3 compatible como MinIO, Wasabi o DigitalOcean Spaces. La guía de autenticación separa usuarios de la aplicación y superusuarios. Si falla SQLite, la app pierde registros. Si falla el almacenamiento, la fila queda visible y el adjunto falta.
Qué se instala o configura primero
El primer entregable verificable son dos colecciones, tres roles y una restauración. En un colegio profesional de Cuyo con 1.800 matriculados, el caso puede empezar por solicitudes de matrícula, comprobantes de pago y cambios de domicilio. Una carpeta de comprobantes con folios numerados muestra el problema social: el orden existe, pero depende de una persona que conoce cada papel. La pila mínima usa PocketBase 0.39.10, proxy HTTPS con Caddy o NGINX, usuarios separados, reglas por colección, almacenamiento local o S3, copia diaria de pb_data y monitoreo de tamaño. La guía de producción indica que para backup o restauración alcanza con copiar o reemplazar pb_data con cuidado transaccional y que PocketBase también tiene backups y APIs de restauración desde la versión 0.16. Con dólar oficial vendedor a ARS 1.520, un VPS chico puede costar entre USD 10 y USD 25 mensuales, entre ARS 15.200 y ARS 38.000. Si se usa S3 compatible, sumar entre USD 5 y USD 20, entre ARS 7.600 y ARS 30.400, según volumen y retención. Un piloto de 18 a 32 horas técnicas a USD 30/h queda entre USD 540 y USD 960, entre ARS 820.800 y ARS 1.459.200. UMSA lo puede entregar con alcance acotado: modelo, roles, importación inicial, backup, restauración y documento de salida.
Dónde se rompe y cómo probarlo
El primer riesgo aparece en reglas demasiado abiertas. La señal es un usuario que puede listar registros ajenos desde la API. La prueba crea dos cuentas de área, carga registros cruzados y verifica que cada una vea solo su universo permitido. El segundo riesgo aparece en archivos sin retención. La señal es un adjunto borrado desde el panel sin evidencia equivalente. La prueba intenta borrar un comprobante desde un rol operativo y exige rechazo o registro de evento. El tercer riesgo aparece en backup copiado con la aplicación escribiendo. La señal es una restauración que abre el panel pero pierde el último registro. La prueba detiene el servicio, copia pb_data, levanta otro servidor y abre una solicitud elegida por gerencia. El cuarto riesgo aparece al venderlo como reemplazo de cualquier sistema. La señal es una colección que empieza a modelar facturación, stock y permisos complejos al mismo tiempo. La prueba limita el piloto a un flujo, escribe criterio de salida y decide qué datos quedan fuera. PocketBase sirve cuando el formulario tiene dueño, permiso y copia que vuelve.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.