Baserow 2.2 en pymes: tablas, API y permisos
Baserow sirve para reemplazar planillas compartidas con tablas, formularios, API y permisos. Flujo técnico, costos, límites y prueba de salida.
Una tabla editable con permisos cambia la discusión cuando la planilla compartida ya tiene diez dueños. Baserow permite armar bases simples, formularios y vistas sin escribir una aplicación desde cero, pero el valor aparece recién cuando cada tabla tiene responsable, API, copia y salida. Esta guía explica qué dato vive en Baserow, qué queda en PostgreSQL y cómo probarlo antes de mover una operación real. ## Dónde la planilla se queda corta Baserow publicó la versión 2.2.2 el 28 de abril de 2026. Las notas de Baserow 2.2 destacan permisos por vista, scanner de datos y mejoras del generador de aplicaciones. Para una cámara empresaria chica, el dato importante es más simple: una tabla deja de circular por correo y pasa a tener roles. La encuesta Stack Overflow 2025 muestra SQL en 58,6 % de respuestas y PostgreSQL en 55,6 % entre bases de datos. La cifra corrige una costumbre de oficina: muchas operaciones todavía se apoyan en una planilla porque parece liviana, aunque el registro después necesite filtros, historial, API y respaldo. El antagonista es la celda pisada. Un tesorero de San Martín puede tener socios, cuotas, certificados y convenios en un archivo compartido. Cuando dos personas ordenan por columnas distintas y una borra una fila, la cámara descubre tarde que no tiene dueño del dato.
Cómo funciona por dentro
El flujo empieza con una base y varias tablas: socios, pagos, contactos, trámites y adjuntos. Cada tabla define campos, tipos, obligatoriedad y vistas. Un formulario carga registros nuevos. Una vista filtrada muestra solo morosos, altas pendientes o certificados listos. La API entrega datos a otra aplicación o recibe cambios desde un sistema externo. Baserow usa backend y frontend separados, comunicados por REST según su documentación de API. La API usa tokens y permisos; una clave de base puede limitar qué tabla y qué operación se permite. El navegador nunca debe tener una credencial capaz de cambiar todo. PostgreSQL guarda las tablas, filas, campos, usuarios, grupos y auditoría técnica. Baserow administra la interfaz, formularios, vistas y validaciones. El almacenamiento de archivos conserva adjuntos cuando se habilitan campos de archivo. El proxy HTTPS publica la aplicación. El backup copia base, archivos y configuración. Los permisos separan carga, revisión y lectura. Administración crea socios y cuotas. Tesorería cambia estados de pago. Comisión directiva lee reportes. Un colaborador externo carga formularios sin ver toda la base. Si se necesita una vista pública, se publica solo esa vista y se revisa que no muestre CUIT, teléfono privado o comentario interno.
Qué se instala o configura primero
La instalación inicial puede seguir la guía de Docker Compose de Baserow, con PostgreSQL, volúmenes persistentes, dominio, TLS, correo y copia diaria. El primer entregable verificable es una base de socios con tres vistas: activos, deuda y certificados por emitir. Con tipo de cambio oficial vendedor de referencia a ARS 1.453 por dólar consultado el 16 de junio, un servidor de USD 22 a 48 mensuales queda entre ARS 31.966 y ARS 69.744. Un piloto demanda 24 a 40 horas: modelo de tablas, roles, formularios, importación corta, API token, tablero de control y prueba de restauración. UMSA puede arrancar con una sola cámara o colegio profesional, sin migrar todo el archivo histórico. El corte inicial debe elegir una operación repetida: alta de socio, certificado, cuota o reclamo. El criterio de salida es que cualquier registro nuevo tenga fecha, responsable, estado y respaldo.
Dónde se rompe y cómo probarlo
El primer riesgo es copiar una planilla mala dentro de una herramienta nueva. La señal aparece cuando hay campos libres para estados que deberían ser lista cerrada. La prueba importa veinte registros con errores y exige que Baserow rechace estados inválidos. El segundo riesgo es publicar una vista con datos privados. La señal aparece cuando una URL pública muestra teléfono, CUIT o comentario interno. La prueba abre la vista en ventana anónima y revisa campo por campo. El tercer riesgo está en PostgreSQL. La documentación de PostgreSQL locking en Baserow advierte que bases con miles de tablas pueden tocar límites de bloqueo en ciertas operaciones. La prueba crea una copia de ambiente, duplica una base grande y mira logs antes de aceptar un diseño con demasiadas tablas. Si el equipo necesita más de unas decenas de tablas para el primer proceso, conviene cortar el alcance y publicar una base por operación. El cuarto riesgo es una API sin dueño. La señal aparece cuando un token sigue activo después de terminar una integración. La prueba lista tokens, revoca uno usado por un script y verifica que la tarea falle de forma registrada. El quinto riesgo es restaurar solo la base. La prueba levanta un backup en ambiente separado, abre una tabla con adjuntos, consulta la API y compara cantidad de registros. Una salida seria se mide cuando la cámara puede reconstruir la base sin llamar al dueño de la planilla vieja.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.