#Dimensionamiento 100 User
Estimación técnica para una instancia Odoo Enterprise 19 instalada en una VPS on-premise para 100 usuarios nominales.
1. Introducción
El propósito de este informe es definir una configuración inicial fundada para operar Odoo Enterprise 19 en infraestructura on-premise con 100 usuarios registrados. El dimensionamiento busca equilibrar rendimiento, margen de crecimiento y capacidad de recuperación, evitando presentar una cifra aislada como garantía de desempeño.
La cantidad de usuarios nominales no determina por sí sola la carga. La capacidad real depende de la concurrencia, los módulos utilizados, la complejidad de las personalizaciones, las tareas programadas, las integraciones, los reportes, el volumen transaccional y el tamaño del filestore. Por ese motivo, la recomendación debe validarse con métricas y una prueba de carga antes de aceptar la capacidad productiva.
2. Requerimientos y supuestos
| Variable | Supuesto de diseño |
|---|---|
| Usuarios nominales | 100 cuentas habilitadas |
| Concurrencia base | 20 %: 20 usuarios simultáneos |
| Concurrencia de crecimiento | 30–45 usuarios simultáneos con ajuste de workers y validación |
| Aplicación | Odoo Enterprise 19 en Linux, modo multiproceso |
| Base de datos | PostgreSQL en la misma VPS |
| Carga | Empresarial media; sin procesos masivos permanentes |
| Disponibilidad | Instancia única; backups y recuperación fuera de la VPS |
La guía oficial de Odoo utiliza como orientación aproximadamente un worker por cada seis usuarios concurrentes. Para 20 concurrentes, el cálculo teórico es ceil(20 / 6) = 4 workers HTTP. Se propone comenzar con 6 workers HTTP y 1 worker cron para disponer de margen operativo, manteniendo el worker de eventos/websocket y el proxy correctamente configurados.
3. Estimación recomendada
| Componente | Base recomendada | Rango superior | Justificación |
|---|---|---|---|
| CPU | 10 vCPU | 12–15 vCPU | Margen para workers Odoo, PostgreSQL, cron, integraciones y picos. Deben ser vCPU de buen rendimiento y sin sobreasignación agresiva. |
| RAM | 24 GB | 32 GB | Cubre workers, PostgreSQL, caché Linux, proxy, monitoreo y margen de seguridad. Usar 32 GB con MRP, inventario intensivo, reportes o integraciones frecuentes. |
| Disco | 500 GB NVMe | 800 GB NVMe | Capacidad para PostgreSQL, filestore, WAL, temporales y logs, conservando margen libre. Los backups deben almacenarse fuera del host. |
| Workers iniciales | 6 HTTP + 1 cron | 8 HTTP + 1–2 cron | Ajustar con CPU, latencia p95 y carga real; más workers no corrigen consultas lentas. |
| Red | 1 Gbps LAN | Enlace redundante según criticidad | Importan la latencia estable, el acceso remoto y la ventana de backup. |
Configuración recomendada de partida
12 vCPU, 32 GB de RAM y 500 GB NVMe, con posibilidad de ampliar a 800 GB. Es una configuración deliberadamente holgada para 20 usuarios concurrentes y permite absorber crecimiento, cron e integraciones sin operar al límite desde el inicio.
3.1 CPU y workers
Odoo documenta dos reglas orientativas: (CPU × 2) + 1 como máximo teórico de workers y aproximadamente un worker por cada seis usuarios concurrentes. Con 10 vCPU, el máximo teórico sería 21; con 15 vCPU, 31. No se recomienda configurar todos esos procesos de inicio: PostgreSQL, cron y el sistema también requieren CPU. Para el requisito base, 6 workers HTTP dejan margen sobre los 4 teóricos.
3.2 Memoria
La fórmula oficial considera 80 % de solicitudes ligeras con 150 MB por worker y 20 % pesadas con 1 GB. Para 7 workers relevantes, la estimación de Odoo es aproximadamente 7 × (0,8 × 150 + 0,2 × 1024) ≈ 2,27 GB solo para workers. La recomendación de 24–32 GB incorpora PostgreSQL, caché de página, sistema operativo, proxy, monitoreo, procesos de fondo y picos de memoria.
3.3 Capacidad y tasa de crecimiento
El disco debe operar con margen. Se adopta un umbral de planificación del 70 % de ocupación, se reservan 40 GB para sistema, logs y temporales, y se supone un volumen inicial combinado de PostgreSQL y filestore de 100 GB.
| NVMe | Techo operativo al 70 % | Crecimiento disponible después de 40 GB de sistema y 100 GB iniciales | A 5 GB/mes | A 10 GB/mes | A 20 GB/mes |
|---|---|---|---|---|---|
| 500 GB | 350 GB | 210 GB | 42 meses | 21 meses | 10 meses |
| 800 GB | 560 GB | 420 GB | 84 meses | 42 meses | 21 meses |
La fórmula reproducible es meses = (capacidad × 0,70 − reserva del sistema − datos iniciales) / crecimiento mensual. Esta tabla mide capacidad, no rendimiento de escritura. Si el volumen inicial o la tasa real cambian, debe recalcularse. Alertar al 60 %, planificar ampliación al 65 % y evitar superar sostenidamente el 70 %.
3.4 Variación de concurrencia
| Concurrentes | Workers HTTP teóricos | Comportamiento esperado con 10–15 vCPU / 24–32 GB |
|---|---|---|
| 20 (20 %) | 4 | Holgado con 6 workers; escenario base. |
| 30 (30 %) | 5 | Compatible con 6–7 workers y monitoreo. |
| 45 (45 %) | 8 | Compatible con 8 workers en el tramo de 12–15 vCPU y 32 GB, sujeto a prueba de carga. |
| 60 (60 %) | 10 | Posible solo con carga moderada, 15 vCPU, 32 GB y PostgreSQL bien ajustado; requiere prueba. |
| 100 (100 %) | 17 | Fuera del supuesto base. Requiere redimensionamiento, prueba integral y posible separación de PostgreSQL. |
Estas bandas no son garantías: una operación MRP, un reporte contable o una integración pesada puede consumir más que varias sesiones livianas. La aceptación debe basarse en CPU sostenida, memoria, latencia de disco, consultas PostgreSQL y tiempos de respuesta p95.
4. Recomendaciones oficiales de Odoo
La documentación oficial de Odoo 19 respalda los criterios usados en este informe:
- System configuration: workers, concurrencia, memoria, proxy, websocket y ejemplo de configuración.
- Source install: Python 3.10 o posterior y PostgreSQL 13 o posterior para Odoo 19.
- Packaged installers: paquetes oficiales y requisito manual de
wkhtmltopdf 0.12.6para encabezados y pies de página. - On-premise: índice oficial de despliegue local.
- Command-line interface: parámetros de ejecución y configuración del servidor.
Las páginas de precios, hardware de POS, IoT, industrias, partners y SLA comercial pueden aportar contexto, pero no fundamentan el dimensionamiento de CPU, RAM, workers o almacenamiento de una VPS on-premise. Por eso no se utilizan como evidencia principal.
4.1 Cómo replicar la consulta en Odoo Help
- Abrir Odoo Help e iniciar sesión si el portal lo solicita.
- Crear una consulta nueva y especificar versión, edición, modalidad, usuarios nominales, concurrencia, ubicación de PostgreSQL y tipo de carga.
- Usar este texto:
Dimensionar Odoo Enterprise 19 on-premise para 100 usuarios nominales, 20 usuarios concurrentes, PostgreSQL en la misma VPS, carga empresarial media. Indicar CPU, RAM, disco, workers, supuestos y citar únicamente documentación oficial de Odoo 19. - Pedir que separe requisitos mínimos, recomendaciones y supuestos; solicitar enlaces directos a cada fuente.
- Abrir los enlaces citados y comprobar manualmente workers, fórmula de memoria, versiones mínimas y configuración del proxy.
- Guardar fecha, texto de la consulta y respuesta. La salida del asistente debe tratarse como orientación; la documentación enlazada y la prueba de carga son la evidencia de aceptación.
5. Validación y criterios de aceptación
- Medir concurrencia real por franja horaria y proceso.
- Relevar módulos, personalizaciones, cron, integraciones y reportes críticos.
- Medir PostgreSQL, filestore, WAL, logs y crecimiento mensual.
- Ejecutar prueba de carga en homologación con datos representativos.
- Monitorear CPU, RAM, latencia e IOPS de disco, bloqueos y consultas lentas.
- Definir backups externos, RPO, RTO y prueba de restauración.
- Revisar la capacidad después de 30, 60 y 90 días de operación.
Dictamen
Para 100 usuarios nominales y 20 % de concurrencia, la configuración de 10–15 vCPU, 24–32 GB de RAM y 500–800 GB NVMe es técnicamente prudente y ofrece margen de crecimiento. Se recomienda implementar 12 vCPU, 32 GB y 500 GB NVMe como punto inicial, conservando ampliación a 800 GB y cerrando la capacidad mediante una prueba de carga.