Por qué autoalojar MongoDB en un VPS
MongoDB Atlas factura por clúster, por GB y por operación, y limita ciertas funcionalidades fuera de los niveles premium. Al desplegar MongoDB en su VPS, monta un replica set completo para la alta disponibilidad, activa el profiler y los índices que quiera, y conserva sus documentos en una infraestructura que usted controla. Es pertinente para una aplicación Node.js/Express, un backend de logs, un catálogo de productos de estructura variable o cualquier sistema donde el esquema evolucione rápido. Con WiredTiger como motor de almacenamiento y un buen dimensionamiento de RAM para el working set, un VPS ofrece un rendimiento totalmente comparable al de una instancia gestionada, a una fracción del coste.
Los beneficios concretos de un MongoDB autoalojado
- Replica set completo (primario + secundarios) en varios VPS para la alta disponibilidad.
- Índices y profiler sin restricción: compound, parciales, TTL, geoespaciales, full-text.
- Control de la caché de WiredTiger para mantener el working set en memoria.
- Sin facturación por operación ni por tamaño de clúster: tarifa de VPS previsible.
- Copias de seguridad mediante
mongodumpo snapshots del volumen, según su volumetría. - Soberanía y acceso completo a los logs, las métricas y la configuración del servidor.
Requisitos de hardware y software
MongoDB aprovecha la RAM para su caché WiredTiger: procure que quepa en ella su working set (los datos y los índices consultados con frecuencia). Para un proyecto de desarrollo o una aplicación pequeña, 2 vCPU y 4 GB de RAM con 40 GB de SSD son suficientes. Para producción con un replica set, prevea 4 vCPU y 8 GB de RAM por nodo, e idealmente tres VPS distintos (uno primario, dos secundarios, o un árbitro para el quórum). En cuanto al software: Ubuntu 22.04/24.04 LTS, Docker y Compose v2, un volumen persistente para /data/db y un sistema de archivos XFS, recomendado por MongoDB para WiredTiger. Un dominio resulta útil (p. ej.: mongo.miapp.com) si expone el acceso por TLS.
Desplegar MongoDB con Docker en producción
Preparar el VPS
Instale Docker, desactive las Transparent Huge Pages (recomendación de MongoDB) y cierre el puerto 27017 hacia el exterior con
ufw deny 27017. Un MongoDB sin autenticación expuesto en Internet es un blanco inmediato de ransomware.Definir el docker-compose.yml
Declare un servicio
mongo:7, monte un volumen en/data/dby paseMONGO_INITDB_ROOT_USERNAMEyMONGO_INITDB_ROOT_PASSWORDmediante.env. Añada el comando--authpara forzar la autenticación desde el arranque.Crear los usuarios de la aplicación
Después de
docker compose up -d, conéctese condocker compose exec mongo mongoshy cree un usuario dedicado a su base de datos con el rolreadWriteúnicamente. Reserve la cuenta root para la administración, nunca para la aplicación.Activar el replica set
Para la alta disponibilidad, arranque cada nodo con
--replSet rs0y después inicialice conrs.initiate()enumerando los miembros. El replica set aporta el failover automático y permite las lecturas en los secundarios (readPreference: secondary).Asegurar el acceso remoto con TLS
Si una aplicación externa se conecta, active TLS con un certificado Let's Encrypt montado en el contenedor (
--tlsMode requireTLS), y utilice la clave interna (--keyFile) para que los miembros del replica set se autentiquen entre sí.Indexar y respaldar
Cree sus índices con
db.collection.createIndex()analizando las consultas medianteexplain(). Programe unmongodumpdiario o, para grandes volúmenes, snapshots coherentes del volumen, y archívelos fuera del VPS.
Active el profiler en modo lento (db.setProfilingLevel(1, { slowms: 100 })) para capturar las consultas que superen los 100 ms, y cruce después esos resultados con explain('executionStats'): la mayoría de los problemas de rendimiento de MongoDB provienen de un índice ausente que fuerza un COLLSCAN. Para las series temporales (logs, métricas), aproveche las colecciones time-series nativas de MongoDB 5+: se comprimen automáticamente y reducen la huella en disco de forma espectacular.
