Técnico
PocketBase 0.40.4 en pymes: reglas, backups y salida
PocketBase resuelve backends chicos con API, reglas y backups en un solo binario. Qué datos guardar, cómo limitar permisos y cómo probar salida.
Un directorio pb_data puede guardar base, archivos y configuración de una aplicación chica; esa comodidad exige una prueba de salida antes de producción. PocketBase 0.40.4 sirve para turnos, formularios internos, inventarios livianos y portales con pocos roles. Esta guía muestra dónde vive el dato, cómo se limitan permisos, qué backup se prueba y cuándo conviene pasar a PostgreSQL. ## Dónde aparece el backend liviano PocketBase combina base SQLite, API HTTP, autenticación, panel de administración y manejo de archivos en un solo binario. La versión 0.40.4 fue publicada el 12 de septiembre de 2026 y corrige un bloqueo de migración ligado a escritura de logs mientras la migración se ejecuta. Esa clase de detalle importa porque una pyme suele actualizar fuera de horario, con una ventana corta y una sola persona mirando la consola. La restauración se prueba con un ZIP real. La comparación útil está en el hábito de los equipos. La encuesta Stack Overflow 2025 mide bases, frameworks y lenguajes usados por desarrolladores; PocketBase se ubica en ese mundo por una decisión práctica: reduce piezas para equipos chicos, mientras mantiene una API documentada y reglas por colección. En una clínica privada de Godoy Cruz, el encargado de sistemas puede entregar un formulario de guardia en días, siempre que escriba quién ve pacientes, quién corrige turnos y quién revisa adjuntos. Ese formulario deja de ser un experimento cuando tiene fecha de alta, responsable, prueba de permisos y copia restaurable. El antagonista es el panel hecho a mano que crece sin permisos escritos y termina con un archivo exportado por chat.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. 1. El usuario carga un registro: turno, activo, solicitud, inspección o archivo. 2. PocketBase guarda el registro en SQLite dentro de pb_data y conserva archivos subidos con metadatos. 3. La regla list, view, create, update o borrado decide si esa cuenta puede ver, crear, editar o borrar. 4. El panel de administración define colecciones, campos, índices y usuarios con rol de superusuario. 5. El backup toma una copia ZIP de pb_data o copia la base con una estrategia externa si el volumen supera varios GB. 6. La prueba de salida restaura ese ZIP en otro servidor y valida un usuario, un archivo y una consulta. Cada regla tiene que leerse en voz operativa. Una colección de reclamos puede permitir que el cliente cree registros, que soporte edite estado, que gerencia vea todos y que nadie borre salvo administración. Si una regla queda vacía por apuro, el sistema responde distinto según acción: lista vacía, error 400, 404 o 403. Esa diferencia ayuda a probar permisos sin mirar código.
Qué se instala o configura primero
La pila de arranque puede ser un VPS 2 vCPU y 4 GB, PocketBase detrás de Caddy con HTTPS, almacenamiento local cifrado, backup diario a S3 compatible y monitoreo de proceso. Un servidor así cuesta entre USD 12 y USD 25 mensuales; al dólar oficial venta de $1.545 equivale a $18.540 a $38.625 por mes. Ese costo incluye cómputo básico; quedan aparte dominio, correo, almacenamiento externo y horas de implementación. UMSA suele proponer PocketBase cuando el primer entregable tiene alcance cerrado: diez pantallas internas, menos de 30 usuarios, archivos chicos y dos o tres roles. El primer día se define el esquema de colecciones. El segundo se escriben reglas y formularios. El tercero se prueba carga, exportación y backup. Si aparecen reportes pesados, auditoría compleja o integración contable, PostgreSQL y un backend más separado entran antes de que la herramienta quede chica.
Dónde se rompe y cómo probarlo
El primer riesgo es tratar pb_data como archivo común. La señal aparece cuando alguien lo copia con la aplicación corriendo y el backup queda inconsistente. La prueba mínima es restaurar la copia en otro directorio y abrir tres registros con archivos adjuntos. El segundo riesgo es dejar reglas demasiado abiertas. La señal aparece cuando una cuenta nueva puede listar registros ajenos. La prueba mínima es ejecutar cinco solicitudes HTTP con usuarios distintos y registrar código de respuesta. El tercer riesgo es crecer sin plan de migración. La señal aparece cuando una consulta tarda varios segundos o el archivo ZIP supera el tiempo de ventana disponible. La prueba mínima es cargar un lote sintético, medir búsqueda y ejecutar restauración cronometrada. PocketBase funciona bien cuando su límite queda escrito. Si el dato sostiene facturación, salud sensible o miles de operaciones diarias, el plan de salida tiene que estar firmado antes del primer usuario real.
