Docker: comparación de montajes — Volume vs Bind Mount con pruebas de rendimiento

La primera vez que usé Docker, lo que más me desorientó fue el montaje de datos. En un entorno de pruebas, el contenedor se reinició de repente; recargué la página y — vacío. Abrí la base de datos y los datos habían desaparecido. Entonces entendí que perder datos al reiniciar un contenedor no es broma.

Quizá te haya pasado algo parecido:

• Montar directorios con -v en la línea de comandos sin saber dónde quedan realmente los datos
• npm install en Mac tan lento que te tomas un café y sigue girando
• Ver a otros usar --mount type=volume sin entender en qué se diferencia de -v
• No saber cuándo usar Volume y cuándo Bind Mount

Al fondo, todo esto se reduce a no entender bien los tres modos de montaje de Docker. Hoy repasamos las diferencias entre Volume, Bind Mount y tmpfs, y en qué escenario conviene cada uno. Con un árbol de decisión y varios casos reales, en 3 minutos podrás elegir el montaje correcto.

Fundamentos de gestión de datos en Docker

¿Por qué se pierden los datos al reiniciar el contenedor?

Primero, una verdad incómoda: los contenedores no están pensados para almacenar datos.

Puedes imaginar un contenedor como un tupper desechable. Comes, tiras el tupper y lo que quedaba dentro se va con él. Igual con el contenedor: si lo eliminas, los datos desaparecen. Y aunque no lo borres, solo reinicies, a veces también pierdes datos.

Por eso necesitamos persistencia: guardar lo importante fuera del contenedor, para que los datos sigan ahí aunque el contenedor vaya y venga.

¿Qué diferencia hay entre -v y --mount?

Cuando empecé con Docker, estos dos parámetros me volvían loco. Hacen básicamente lo mismo, pero la sintaxis es distinta.

Por ejemplo, montar un volumen en /data del contenedor:

# Opción 1: con -v (breve, pero fácil de confundir)
docker run -v myvolume:/data nginx

# Opción 2: con --mount (más largo, pero claro)
docker run --mount type=volume,source=myvolume,target=/data nginx

¿Ves la diferencia? Con -v solo hay dos puntos: origen y destino. Simple, pero no se ve si es Volume o Bind Mount.

Con --mount queda explícito: type=volume indica un montaje Volume. Cada parámetro está claro. Escribes más, pero seis meses después entiendes el comando de un vistazo.

Mi recomendación: --mount en producción, -v cuando experimentas.

Esta tabla ayuda a comparar:

[Imagen: diagrama comparativo de comandos]
Prompt: terminal screen showing docker run commands with -v and —mount side by side, modern tech style, blue and green colors, high quality

Comparación profunda de los tres modos de montaje

Vamos al grano. Docker ofrece tres modos: Volume, Bind Mount y tmpfs. Cada uno tiene su carácter; usado bien ahorra dolores de cabeza, mal usado te mete en un agujero.

Volume: deja que Docker sea tu mayordomo

Volume es como contratar un mayordomo. Le dices «gestiona estos datos» y los guarda en un sitio dedicado (en Linux, /var/lib/docker/volumes/). No tienes que preocuparte por los detalles.

Lo que más valoro de Volume: rendimiento estable entre plataformas. En Linux, Mac o Windows, Volume se comporta de forma similar. En equipos eso evita el clásico «en mi máquina va bien».

Volume también se gestiona con comandos de Docker:

# Crear un Volume
docker volume create my-data

# Ver todos los Volume
docker volume ls

# Ver detalles del Volume (dónde están los datos)
docker volume inspect my-data

# Hacer backup del Volume (muy sencillo)
docker run --rm -v my-data:/data -v $(pwd):/backup alpine tar czf /backup/backup.tar.gz /data

¿Cuándo usar Volume?

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

• Bases de datos como MySQL o PostgreSQL (seguridad de datos primero)
• Datos compartidos entre varios contenedores (por ejemplo, subidas de archivos)
• Datos persistentes en producción (fácil de respaldar y migrar)

[Imagen: diagrama de funcionamiento de Volume]
Prompt: Docker volume management diagram, Docker managing storage volumes, clean infographic style, blue and white colors, high quality

Bind Mount: tú mandas en casa

Bind Mount es distinto: monta directamente un directorio del host en el contenedor. Tú eliges la ruta; Docker no interviene.

Su gran ventaja es la sincronización en tiempo real. Cambias código en local y el contenedor lo ve al instante. En desarrollo es ideal: editas, recargas la página y ves el resultado sin reconstruir la imagen.

Pero Bind Mount tiene un trampa en Mac y Windows.

Paolo Mainardi hizo pruebas en 2025: en Mac, npm install con Bind Mount fue 3,5 veces más lento que con Volume. ¿Por qué? Docker Desktop en Mac usa virtualización; cada acceso a archivos en Bind Mount cruza el límite de la VM, y el coste es enorme.

# Ejemplo de Bind Mount (montar el directorio actual en el contenedor)
docker run -d \
  --name my-app \
  --mount type=bind,source=$(pwd),target=/app \
  node:18

# O con -v (mismo efecto)
docker run -d --name my-app -v $(pwd):/app node:18

¿Cuándo usar Bind Mount?

• Entorno de desarrollo local (ver cambios de código al instante)
• Montar archivos de configuración (nginx.conf, .env, etc.)
• Sacar logs al host para consultarlos fácilmente

¿Cuándo evitarlo?

• En Mac/Windows, no montes node_modules, vendor ni directorios de dependencias similares con Bind Mount (desastre de rendimiento)
• Con cuidado en producción (dependencia fuerte de rutas; en otra máquina puede fallar)

tmpfs: la nota adhesiva en memoria

tmpfs es especial: guarda datos en memoria. Al parar el contenedor, todo desaparece. Suena inútil, pero en ciertos casos es oro.

La memoria es decenas o cientos de veces más rápida que el disco. Si los datos son temporales (caché de Redis, tokens, sesiones), ¿por qué no usar el almacenamiento más rápido?

# Ejemplo tmpfs (100 MB en memoria)
docker run -d \
  --name fast-cache \
  --mount type=tmpfs,target=/cache,tmpfs-size=100M \
  redis:7

¿Cuándo usar tmpfs?

• Caché temporal (no hace falta persistir)
• Datos sensibles temporales (en memoria desaparecen al apagar; más seguro)
• Escenarios de rendimiento extremo (por ejemplo, análisis de logs en tiempo real)

Nota: tmpfs solo funciona en contenedores Linux; Docker Desktop en Mac y Windows no lo soporta.

Comparación de los tres modos

Juntos, las diferencias quedan claras:

Con esta tabla ya tienes una idea clara.

Guía de elección por escenario

¿Sigues dudando qué usar en tu proyecto?

Tranquilo: aquí va un árbol de decisión; tres preguntas y listo:

Árbol de decisión rápido

Pregunta 1️⃣: ¿Los datos deben persistir?
  ├─ No (caché, archivos temporales) → tmpfs
  └─ Sí → Pregunta 2️⃣

Pregunta 2️⃣: ¿Entorno de desarrollo o producción?
  ├─ Producción → Volume
  └─ Desarrollo → Pregunta 3️⃣

Pregunta 3️⃣: ¿Necesitas modificar archivos en tiempo real (p. ej. código)?
  ├─ Sí → Bind Mount
  │   └─ ¿Mac/Windows? → Volume para node_modules y dependencias
  └─ No → Volume

¿Sigue abstracto? Veamos escenarios reales.

Escenario 1: base de datos MySQL

Con una base de datos, perder datos es fatal. Volume sin dudarlo.

# Crear contenedor MySQL (recomendado)
docker run -d \
  --name mysql \
  --mount type=volume,source=mysql-data,target=/var/lib/mysql \
  -e MYSQL_ROOT_PASSWORD=my-secret-pw \
  mysql:8.0

# Ver información del Volume
docker volume inspect mysql-data

¿Por qué Volume?

• ✅ Datos seguros, gestionados por Docker
• ✅ Backup sencillo (un comando)
• ✅ Rendimiento consistente entre plataformas
• ✅ Migración a otro servidor más fácil

[Imagen: diagrama de almacenamiento MySQL con Volume]
Prompt: MySQL database with Docker volume storage, data persistence visualization, professional tech illustration, blue and orange colors, high quality

Escenario 2: desarrollo Node.js en Mac

Caso clásico: desarrollar Node.js en Mac, ver cambios de código al instante y que npm install no sea una tortura. ¿Qué hacer?

Enfoque mixto: código con Bind Mount, dependencias con Volume.

# Contenedor de desarrollo Node.js
docker run -d \
  --name my-node-app \
  --mount type=bind,source=$(pwd)/src,target=/app/src \
  --mount type=bind,source=$(pwd)/package.json,target=/app/package.json \
  --mount type=volume,source=node-modules-cache,target=/app/node_modules \
  -p 3000:3000 \
  node:18 \
  npm run dev

Fíjate:

• src con Bind Mount → cambios de código al instante
• package.json con Bind Mount → ves cambios de dependencias
• node_modules con Volume → evitas el agujero de rendimiento en Mac

En la primera ejecución, instala dependencias:

# Entrar al contenedor e instalar dependencias
docker exec my-node-app npm install

Así, npm install puede ser más de 3 veces más rápido. En mis pruebas, de 2 minutos pasó a unos 40 segundos.

Escenario 3: configuración de Nginx

En ops pasa seguido: cambias la config de Nginx, reinicias el contenedor y la config desaparece. ¿Solución?

Bind Mount para el archivo de configuración, con readonly para más seguridad.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

# Montar config de Nginx (solo lectura)
docker run -d \
  --name nginx \
  --mount type=bind,source=$(pwd)/nginx.conf,target=/etc/nginx/nginx.conf,readonly \
  -p 80:80 \
  nginx:latest

# Tras cambiar la config, recargar (sin reiniciar el contenedor)
docker exec nginx nginx -s reload

¿Por qué Bind Mount?

• ✅ Cambios de config al instante
• ✅ Archivo en el host, fácil de gestionar
• ✅ Modo readonly evita que el contenedor modifique la config

Escenario 4: caché temporal con Redis

Redis como caché: los datos son temporales; si se pierden, se regeneran. tmpfs encaja perfecto.

# Redis con tmpfs (máximo rendimiento)
docker run -d \
  --name redis-cache \
  --mount type=tmpfs,target=/data,tmpfs-size=512M \
  -p 6379:6379 \
  redis:7 \
  redis-server --save ""

# Nota: --save "" desactiva persistencia RDB (los datos están en memoria)

¿Por qué tmpfs?

• ✅ Lectura/escritura en memoria, lo más rápido
• ✅ La caché no necesita persistir
• ✅ Al reiniciar el contenedor se limpia solo, coherente con caché

Cuidado: tmpfs solo en contenedores Linux. Docker Desktop en Mac no lo soporta.

Escenario 5: recolección de logs

En desarrollo quieres ver logs del contenedor sin ejecutar docker logs cada vez. Monta logs en el host.

# Montar directorio de logs en el host
docker run -d \
  --name my-app \
  --mount type=bind,source=$(pwd)/logs,target=/app/logs \
  my-app:latest

# Ver logs en tiempo real en el host
tail -f logs/app.log

Los archivos quedan en local: VSCode, grep, subir a una plataforma de análisis — como prefieras.

Optimización de rendimiento y trampas habituales

Después de los escenarios, las trampas que más veo. Las he pisado yo; si las conoces antes, ahorras tiempo.

Trampa 1: desastre de rendimiento en Mac/Windows

¿Recuerdas las pruebas de Paolo Mainardi? En Mac, Bind Mount es 3,5 veces más lento que Volume. No es poco: npm install de 40 segundos puede pasar a 2 minutos.

¿Por qué tan lento?

Docker en Mac y Windows corre en una VM. Con Bind Mount, cada lectura/escritura cruza ese límite. El coste es enorme, sobre todo en node_modules con miles de archivos pequeños.

Solución:

# Método 1: dependencias con Volume, código con Bind Mount (recomendado)
docker run -d \
  --mount type=bind,source=$(pwd)/src,target=/app/src \
  --mount type=volume,source=deps,target=/app/node_modules \
  node:18

# Método 2: si debes usar Bind Mount, añade :cached (solo Docker Desktop)
docker run -d -v $(pwd):/app:cached node:18

¿Qué es :cached? Le dice a Docker: «el host manda; el contenedor puede sincronizar con retraso». Reduce algo el coste, pero Volume sigue siendo mejor.

Trampa 2: permisos (no se puede escribir en el contenedor)

Muy común: el contenedor arranca y la app devuelve «Permission denied».

Causa: el UID del usuario en el contenedor no coincide con el del host.

Por ejemplo, en el host eres UID 1000 y montas un directorio. En el contenedor la app corre como UID 0 (root) o UID 999. Los UID no coinciden y los permisos se rompen.

Solución:

# Método 1: ejecutar el contenedor con tu UID
docker run --user $(id -u):$(id -g) \
  --mount type=bind,source=$(pwd),target=/app \
  node:18

# Método 2: definir usuario en el Dockerfile
FROM node:18
RUN useradd -m -u 1000 appuser
USER appuser
WORKDIR /app

Yo suelo usar el método 1, directo. El 2 encaja cuando empaquetas imagen.

Trampa 3: rutas en Windows

En Windows las rutas son C:\Users\...; escribirlas así en Docker suele fallar.

Forma correcta:

# PowerShell (recomendado)
docker run -v ${PWD}:/app node:18

# CMD (consola clásica)
docker run -v %cd%:/app node:18

# Git Bash (entorno tipo Unix)
docker run -v /c/Users/yourname/project:/app node:18

# O con doble barra
docker run -v //c/Users/yourname/project:/app node:18

¿Confuso? Usa docker-compose; maneja las rutas automáticamente.

Trampa 4: Volume se acumulan y el disco se llena

Volume va bien, pero al borrar contenedores los Volume no se eliminan solos. Con el tiempo, /var/lib/docker/volumes/ puede llenar el disco.

Limpieza periódica:

# Ver todos los Volume
docker volume ls

# Ver Volume no usados (huérfanos)
docker volume ls -f dangling=true

# Limpiar Volume no usados (¡cuidado!)
docker volume prune

# Más agresivo: contenedores, imágenes, redes y Volume
docker system prune -a --volumes

Yo ejecuto docker volume prune una vez por semana. Los Volume de prueba no merecen ocupar disco.

Trampa 5: ¿dónde están los datos del Volume? Quiero backup manual

Muchos no saben dónde viven los datos del Volume. Es sencillo:

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

# Ver la ruta real del Volume
docker volume inspect my-data

# En la salida, busca el campo "Mountpoint"
# Suele ser: /var/lib/docker/volumes/my-data/_data

No recomiendo tocar ese directorio a mano (permisos). Backup con comandos de Docker es más fiable:

# Backup del Volume a archivo tar
docker run --rm \
  -v my-data:/source \
  -v $(pwd):/backup \
  alpine \
  tar czf /backup/my-data-backup.tar.gz -C /source .

# Restaurar backup en un Volume nuevo
docker run --rm \
  -v new-data:/target \
  -v $(pwd):/backup \
  alpine \
  tar xzf /backup/my-data-backup.tar.gz -C /target

Lo uso para migrar bases de datos en producción; funciona muy bien.

[Imagen: diagrama de flujo de backup de Volume]
Prompt: Docker volume backup workflow diagram, tar archive process, clean technical illustration, green and blue colors, high quality

Mejores prácticas con docker-compose

Hasta aquí todo con docker run. En proyectos reales suele usarse docker-compose. Aquí un ejemplo completo con los tres modos de montaje.

Ejemplo completo de docker-compose.yml

Arquitectura típica: frontend Node.js + API + PostgreSQL + caché Redis.

version: '3.8'

services:
  # Aplicación web (desarrollo)
  web:
    image: node:18
    container_name: my-web-app
    working_dir: /app
    command: npm run dev
    ports:
      - "3000:3000"
    volumes:
      # Código fuente: Bind Mount (cambios en tiempo real)
      - type: bind
        source: ./src
        target: /app/src
      # package.json: Bind Mount (ver cambios de dependencias)
      - type: bind
        source: ./package.json
        target: /app/package.json
      # node_modules: Volume (evitar problemas de rendimiento en Mac)
      - type: volume
        source: node-modules
        target: /app/node_modules
    environment:
      - NODE_ENV=development
    depends_on:
      - db
      - cache

  # Base de datos (configuración de producción)
  db:
    image: postgres:15
    container_name: postgres-db
    ports:
      - "5432:5432"
    volumes:
      # Datos: Volume (persistencia + backup)
      - type: volume
        source: postgres-data
        target: /var/lib/postgresql/data
      # Script de inicialización: Bind Mount (solo lectura)
      - type: bind
        source: ./init.sql
        target: /docker-entrypoint-initdb.d/init.sql
        read_only: true
    environment:
      - POSTGRES_USER=myuser
      - POSTGRES_PASSWORD=mypassword
      - POSTGRES_DB=mydb

  # Caché Redis (alto rendimiento)
  cache:
    image: redis:7
    container_name: redis-cache
    ports:
      - "6379:6379"
    volumes:
      # Datos temporales: tmpfs (máximo rendimiento, sin persistencia)
      - type: tmpfs
        target: /data
        tmpfs:
          size: 100M  # Limitar uso de memoria
    command: redis-server --save ""  # Desactivar persistencia RDB

  # Proxy inverso Nginx
  nginx:
    image: nginx:latest
    container_name: nginx-proxy
    ports:
      - "80:80"
    volumes:
      # Config: Bind Mount (fácil de editar, solo lectura)
      - type: bind
        source: ./nginx.conf
        target: /etc/nginx/nginx.conf
        read_only: true
      # Logs: Bind Mount (fácil de consultar)
      - type: bind
        source: ./logs/nginx
        target: /var/log/nginx
    depends_on:
      - web

# Declaración de volumes de nivel superior
volumes:
  node-modules:
    driver: local
  postgres-data:
    driver: local
    # Opcional: driver_opts para estrategia de backup, etc.

Notas de configuración (lo importante)

Estrategia de montaje de la app web:

• src con Bind Mount: cambias código y el contenedor lo ve al instante; hot reload perfecto
• node_modules con Volume: imprescindible en Mac; evita el agujero de rendimiento
• package.json con Bind Mount: tras añadir dependencias, entra al contenedor y ejecuta npm install

Estrategia de la base de datos:

• Directorio de datos con Volume: persistencia de nivel producción, gestionado por Docker
• Script de init con Bind Mount + read_only: solo al crear la BD por primera vez; evita modificaciones accidentales

Estrategia de Redis:

• tmpfs: la caché no necesita persistir; velocidad de memoria
• Limitar size: 100M: evita que Redis se coma toda la RAM

Estrategia de Nginx:

• Config con read_only: el contenedor no puede alterar la config
• Logs con Bind Mount: tail -f en el host en tiempo real

Comandos útiles

# Arrancar todos los servicios
docker-compose up -d

# Ver todos los Volume
docker-compose exec web ls -la /app/node_modules  # Comprobar dependencias

# Instalar dependencias (primera vez)
docker-compose exec web npm install

# Recargar config de Nginx (sin reiniciar contenedor)
docker-compose exec nginx nginx -s reload

# Backup del Volume de la base de datos
docker run --rm \
  -v blog-write-agent_postgres-data:/source \
  -v $(pwd):/backup \
  alpine tar czf /backup/db-backup.tar.gz -C /source .

# Parar y limpiar (los Volume no se borran)
docker-compose down

# Parar y eliminar Volume (¡cuidado con pérdida de datos!)
docker-compose down -v

Optimización exclusiva para Mac/Windows

Si desarrollas en Mac o Windows, la config de arriba ya está optimizada. Puedes ir un paso más:

# En el servicio web
volumes:
  - ./src:/app/src:cached  # Modo cached, menos coste de sincronización

:cached indica a Docker: el host manda; el contenedor puede sincronizar con retraso. Mejora rendimiento un 20-30 %.

[Imagen: diagrama de arquitectura docker-compose]
Prompt: Docker compose multi-container architecture, web app database redis nginx, professional system diagram, blue and purple gradient, high quality

Resumen

Repasemos lo esencial.

Los tres modos de montaje en Docker son tres herramientas:

• Volume: Docker gestiona por ti; tranquilo, estable, multiplataforma
• Bind Mount: tú gestionas archivos; flexible, en tiempo real, pero cuidado con el rendimiento
• tmpfs: nota en memoria; rapidísimo, desechable

Tres frases para elegir:

1. Datos de producción → Volume (bases de datos, archivos persistentes)
2. Código de desarrollo → Bind Mount (cambios en tiempo real, hot reload)
3. Datos temporales → tmpfs (caché, información sensible)

Atención en Mac/Windows:

• Nunca Bind Mount para node_modules, vendor y dependencias similares; con Volume vas más de 3 veces más rápido
• Si debes usar Bind Mount, añade :cached

Acción final: toma un proyecto en curso, convierte docker run en docker-compose.yml, usa Volume, Bind Mount y tmpfs, ejecútalo y nota la diferencia. Elegir bien el montaje mejora rendimiento y ordena la estructura del proyecto.

Si tienes dudas, comenta abajo. Yo también aprendí a base de tropiezos; entre todos avanzamos.