FerretDB frente a MongoDB: decisión, costo y límite
FerretDB permite ejecutar aplicaciones compatibles con MongoDB sobre PostgreSQL. La guía revisa flujo, permisos, backup y pruebas de compatibilidad.
FerretDB recibe consultas con protocolo MongoDB y las traduce a PostgreSQL con la extensión DocumentDB. Esa pieza sirve cuando una pyme quiere correr una aplicación compatible con MongoDB sin sumar otra base al inventario. FerretDB v2.7.0 es la versión publicada en GitHub, y la decisión técnica empieza por compatibilidad, backup y permisos. Esta guía muestra qué probar antes de migrar datos reales.
Dónde aparece la decisión de base
El antagonista suele ser la base documental que nació en un prototipo y terminó dentro de un sistema de turnos, órdenes o historias de soporte. El encargado de sistemas de una clínica privada en Godoy Cruz puede aceptar la sintaxis MongoDB que trae la aplicación, pero necesita saber dónde vive el dato y qué herramienta restaura el servicio si falla. La cifra que corrige el entusiasmo está en el propio proyecto: al presentar FerretDB 2.0, el equipo informó mejoras de rendimiento de más de 20 veces impulsadas por DocumentDB. El salto cuenta una historia concreta: las primeras versiones resolvían compatibilidad, y las versiones 2.x mueven el peso hacia PostgreSQL con una extensión especializada. Stack Overflow 2025 suma otro dato: en 26.083 respuestas sobre bases de datos, PostgreSQL fue la tecnología más admirada y deseada de su categoría. FerretDB se entiende mejor como un traductor de protocolo. La aplicación sigue usando drivers y comandos compatibles con MongoDB; FerretDB recibe esa conversación, valida lo que soporta y escribe en PostgreSQL. La decisión técnica no termina ahí, porque el backup, los permisos y las consultas raras se prueban antes de poner usuarios reales.
Cómo funciona por dentro
El flujo empieza en la aplicación. Un formulario guarda un turno, una orden o un documento y el driver MongoDB envía la operación. FerretDB recibe el protocolo MongoDB 5.0 o superior, revisa compatibilidad y transforma la operación en SQL hacia PostgreSQL con DocumentDB. PostgreSQL guarda los documentos, índices y metadatos de la base; el equipo IT administra usuarios, roles y backups desde herramientas conocidas. 1. La aplicación envía lectura o escritura con driver MongoDB. 2. FerretDB valida la operación y la traduce hacia PostgreSQL. 3. PostgreSQL guarda documentos y estados dentro del motor relacional. 4. Los permisos separan usuario de aplicación, usuario de lectura y operador de backup. 5. El monitoreo mide errores de compatibilidad, latencia y conexiones. 6. WAL, dump o snapshot recuperan la base; una prueba abre la aplicación restaurada. PostgreSQL recibe datos estructurados y registros documentales. La documentación oficial de backups distingue copia SQL, copia de archivos y archivado continuo con WAL. Esa diferencia importa: una restauración de FerretDB debe devolver la base y permitir que la aplicación repita las consultas usadas por clientes internos.
Qué se instala o configura primero
El primer piloto no debería empezar con toda la base histórica. Conviene levantar PostgreSQL 17, DocumentDB, FerretDB v2.7.0, un proxy TLS como Caddy y un usuario de aplicación con permisos limitados. El entregable inicial es un set de 30 operaciones reales: alta, edición, búsqueda, índice, borrado controlado y exportación. Cada operación debe correr contra FerretDB y contra el entorno actual para comparar respuesta. El chequeo de salida se arma al mismo tiempo. Un dump lógico, una copia con WAL y una exportación de documentos de muestra quedan fechados en el paquete del piloto. Si la migración se frena, esos archivos permiten volver al estado anterior sin discutir qué parte de la prueba quedó pendiente. Con dólar oficial vendedor a ARS 1.515, un piloto de 20 a 30 horas técnicas a USD 30/h queda entre USD 600 y USD 900, es decir entre ARS 909.000 y ARS 1.363.500. Incluye instalación, set de pruebas, backup, monitoreo básico y una restauración. Quedan fuera migración completa de datos, rediseño de la aplicación y soporte comercial. UMSA puede encarar esta migración cuando una organización quiere reducir bases distintas y mantener PostgreSQL como operación principal. La ganancia verificable no es el nombre de la herramienta: es una app restaurada con las mismas consultas y permisos medidos.
Dónde se rompe y cómo probarlo
El primer riesgo es compatibilidad incompleta. La señal aparece cuando una consulta usa un operador que FerretDB rechaza o ejecuta distinto. La prueba lista las 20 consultas más usadas por la aplicación y registra respuesta, tiempo y diferencias de resultado. El segundo riesgo es tratar a PostgreSQL como caja negra. Si el equipo solo mira FerretDB, pierde autovacuum, crecimiento de índices y WAL. La prueba fuerza carga, revisa tamaño de tablas, revisa logs y confirma que el archivado continuo permite recuperar un punto anterior. El tercer riesgo está en permisos amplios. Si la aplicación usa un usuario con privilegios de administración, un error borra colecciones o índices. La prueba intenta borrar una colección desde usuario de aplicación y espera rechazo o registro trazable. La decisión queda lista cuando una restauración abre la aplicación, ejecuta las consultas principales y muestra qué operadores quedaron fuera del piloto.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.