¿Cuánta RAM necesita un NAS? Guía por sistema y uso 2026

Actualizado: 2026-07-23· Verificado por última vez en julio 2026

Pocas preguntas sobre NAS reciben una respuesta tan inflada como esta. Pregunta en un foro cuánta RAM necesita tu equipo y alguien citará una regla que escala con el tamaño del disco, otro insistirá en que 64 GB son el mínimo sensato, y un tercero te contará que su Synology de cuatro discos lleva una década corriendo con 2 GB sin un tropiezo. Los tres describen máquinas distintas haciendo trabajos distintos, y por eso una sola cifra nunca encaja. La cantidad de memoria que necesita un NAS la fija casi por completo el software que corre y los extras que le montas encima, así que la forma útil de responder es por sistema: con cifras concretas y una nota sobre cuándo cada una debería subir. Si buscas el panorama más amplio de cómo el sistema operativo dirige el resto de decisiones de hardware, eso vive en nuestra guía de hardware para NAS; aquí nos quedamos estrechos y respondemos la pregunta de la RAM directo.

La respuesta corta, y luego la tabla

El mecanismo que explica casi todo lo de abajo es simple: un NAS usa la memoria libre como caché de los archivos tocados recientemente, por eso se siente rápido cuando los datos están calientes y devuelve esa memoria en el instante en que una aplicación la pide. Por eso "RAM libre es RAM desperdiciada" es un lema justo, y por eso una caja que "usa" casi toda su memoria no es una caja que ande corta de ella. La capacidad en bruto apenas mueve la cifra, porque cachear una biblioteca de 40 TB y una de 4 TB cuesta más o menos la misma huella en reposo; lo que la mueve son los programas que corren, ya sean VMs, contenedores o una función de ZFS que cambia memoria por una ganancia concreta. La tabla de abajo es la respuesta corta para los cinco sistemas que la gente instala de verdad.

Lee la tabla como un piso y un objetivo cómodo, no como un techo: nada se rompe si montas más, y la columna "sube cuando" es el disparador honesto para gastar. La conclusión es que para un primer NAS cuyo trabajo son archivos, backups y quizá un par de apps, 8 GB son un aterrizaje sensato en casi cualquier sistema, y las secciones de abajo explican por qué cada uno queda donde queda.

NAS de fábrica: Synology DSM y QNAP

Un equipo sellado está afinado para sentirse ágil con poca memoria, así que los 2 a 4 GB de fábrica de un Synology o QNAP de entrada alcanzan de verdad para el trabajo central: compartir archivos y correr backups. ASUSTOR, que vende la misma clase de caja, lo dice claro en su propia guía: 2 a 4 GB sobran para almacenamiento y uso compartido de archivos básicos, y 8 GB o más empiezan a valer la pena cuando entran virtualización, varias apps o servicios más pesados. En el momento en que tu equipo deja de ser un servidor de archivos y pasa a ser un pequeño servidor de aplicaciones, esa cifra de fábrica queda justa.

Lo que de verdad hace que un equipo pida más RAM es predecible: un stack de contenedores Docker, Synology Surveillance Station grabando varias cámaras, una biblioteca de Fotos construyendo su índice de caras y objetos, o una VM ligera. La trampa a vigilar es que muchos modelos de entrada de dos y cuatro bahías traen la memoria soldada a la placa, así que la RAM que compras el primer día es la que te quedas. Si ya sabes que quieres contenedores, grabación de cámaras o indexación de fotos, la jugada concreta es elegir un nivel de modelo que venga con 8 GB o exponga un slot SODIMM, en lugar de ahorrar veinte euros en una caja que no puedes crecer. Qué nivel es ese depende de la misma decisión de plataforma que trabaja nuestra guía de compra de NAS.

OpenMediaVault y Debian puro: la base de RAM baja

OpenMediaVault se sienta en el extremo frugal de la escala porque es una capa fina de gestión sobre Debian Linux, y Debian se contenta con muy poco. Los propios requisitos de hardware del proyecto listan 1 GiB de RAM como mínimo, por eso OpenMediaVault es la elección clásica para una Raspberry Pi o un mini-PC reciclado sirviendo un par de discos. En la práctica, 2 a 4 GB te dan margen cómodo para la interfaz web, los recursos SMB y un puñado de plugins sin pensar nunca en la memoria.

La cifra solo empieza a importar cuando extiendes OpenMediaVault con los plugins de Docker y Portainer y arrancas contenedores, momento en que los contenedores, no el sistema base, pasan a ser el presupuesto. Como una caja Debian u OpenMediaVault normal usa ext4 o Btrfs en vez de ZFS, no hay un caché ARC reclamando memoria en silencio, así que lo que asignas a los contenedores se acerca a lo que la máquina consume. La conclusión: para un servidor de archivos simple en OpenMediaVault, 4 GB son generosos, y solo planeas más cuando sabes que la lista de contenedores crece. Si lo comparas con las alternativas, nuestra comparativa Unraid vs. TrueNAS vs. OpenMediaVault mapea dónde encaja cada uno.

Unraid: el array es barato, los extras no

Unraid es el ejemplo más claro de por qué la capacidad en bruto es la referencia equivocada para dimensionar la RAM. Su array lee y escribe un disco a la vez en lugar de repartir entre todos, así que el array en sí es poco exigente con la memoria por muchos terabytes que guarde, y unos modestos 4 GB corren la parte de almacenamiento sola. La razón por la que la gente mete 16, 32 o 64 GB en una caja Unraid no tiene nada que ver con el array y todo que ver con lo que le apila encima.

Esa capa es donde va el presupuesto real: los contenedores Docker que corren la mayoría de usuarios de Unraid, una o varias máquinas virtuales, y la memoria que un pool de caché NVMe activo agradece tener alrededor. Un servidor multimedia con una docena de contenedores más una VM de Windows es una máquina genuinamente distinta de un servidor de archivos pelado, y 8 GB son una base cómoda para el array más un conjunto ligero de contenedores, mientras que el salto a más RAM lo dicta tu lista concreta de apps y VMs. Como el autoalojamiento es el propósito entero de la mayoría de builds de Unraid, nuestra guía de autoalojamiento en el NAS es el mejor lugar para dimensionar ese apetito de contenedores, y la comparativa de sistemas enlazada arriba cubre dónde gana y pierde el modelo de un disco de Unraid. La conclusión: dimensiona la RAM de Unraid sumando contenedores y VMs, y trata el array como casi gratis.

TrueNAS y ZFS: el mito de 1 GB por TB

Este es el sistema alrededor del cual se construyó el folclore, así que merece la corrección más clara. ZFS trata la memoria libre como un caché de lectura llamado Adaptive Replacement Cache, o ARC, que equilibra los datos usados recientemente contra los usados con frecuencia para que un pool caliente se sienta rápido incluso en discos giratorios. Como ese caché se expande para llenar la RAM que le des y se encoge en el instante en que una aplicación necesita memoria, más RAM compra sobre todo lecturas más rápidas en lugar de cumplir un requisito rígido, justo lo contrario de cómo lo plantea la regla de "1 GB por TB".

Las cifras honestas son mucho más suaves que la regla. La guía de hardware de TrueNAS trata 8 GB como el piso de trabajo y orienta la mayoría de builds hacia 16 GB, lo que significa que un pool multimedia doméstico de 40 TB corre perfecto con 16 o 32 GB en lugar de los 40 GB que exigiría la regla popular. Lo único que escala de verdad con la capacidad es la deduplicación, que la misma guía cifra en unos 5 GB de RAM por TB de datos deduplicados, y el dedup es una función que activas a propósito, no un valor por defecto. Vale saber que la regla general no se ha esfumado del todo: incluso los requisitos de sistema de Proxmox siguen listando alrededor de 1 GB de memoria por TB cuando el host corre ZFS, como cifra de planificación conservadora y no como un muro. Donde la RAM extra gana su lugar de verdad en ZFS es más estrecho de lo que se cree: dedup como arriba, pools cargados de metadatos con millones de archivos pequeños, y cargas multiusuario o de virtualización donde un caché mayor sube la tasa de aciertos. Para la historia completa del ARC, más ECC, HBAs y dispositivos de caché, nuestro análisis a fondo de requisitos de hardware de ZFS baja un nivel; la conclusión aquí: arranca un pool ZFS doméstico en 16 GB, sube a 32 GB con muchos usuarios o VMs, y persigue una cifra por TB solo si activas dedup a propósito.

Proxmox y virtualización: las VMs fijan el presupuesto

Proxmox le da la vuelta a todo el planteamiento, porque un host de virtualización lo define sus invitados, no su almacenamiento. El hipervisor en sí es ligero: los requisitos de Proxmox VE piden unos 2 GB para el sistema operativo y sus servicios, y luego cada máquina virtual y contenedor suma su asignación fija encima. Una VM de Windows a la que le das 8 GB de verdad saca 8 GB del pool, así que la aritmética de memoria es aditiva de una forma que nunca lo es en un servidor de archivos normal.

Eso convierte el dimensionado en una lista de la compra más que en una regla: suma lo que necesita cada VM y contenedor planeado, añade los pocos gigabytes del host y deja margen para el ARC de ZFS si el host usa almacenamiento ZFS. Un homelab que corre unas cuantas VMs más un stack de contenedores aterriza de forma realista en 16 a 32 GB, y los labs más pesados suben desde ahí. Como es la carga la que lo dirige, aplica la misma planificación de autoalojamiento: decide primero los servicios, luego compra la RAM que suman. La conclusión: presupuesta la RAM de Proxmox para los invitados, trata el host como un error de redondeo y deja siempre espacio para levantar una máquina más.

Qué consume RAM de verdad, y qué no

En cuanto dejas de dimensionar la memoria contra el tamaño del disco, ayuda saber qué cargas la consumen de verdad y cuáles son inocentes en silencio, porque justo en esa diferencia pasa la mayoría del gasto de más. La lista de abajo ordena a los sospechosos habituales, y las dos últimas entradas son las que más se entienden al revés.

• Máquinas virtuales: el mayor consumidor individual, porque le asignas un bloque fijo de RAM a cada una y queda reservado mientras la VM corre.
• Contenedores Docker: modestos por separado, pero suman a lo largo de un stack, y los que llevan base de datos como Immich o Nextcloud pesan más que un contenedor utilitario simple.
• Deduplicación de ZFS: el origen real de la regla por TB, con unos 5 GB de RAM por TB de datos deduplicados, por eso es una función opcional y no un valor por defecto.
• Caché: usa toda la memoria libre como caché de lectura, así que valores altos de "usado" son normales y sanos; el sistema devuelve esa memoria en el instante en que un programa la necesita.
• Transcodificación de video: la famosa falsa alarma: es trabajo de CPU o GPU, no un problema de RAM. La propia doc de Jellyfin describe descargar la transcodificación al vuelo en una GPU para correr eficiente sin forzar la CPU, y ni Plex ni Jellyfin convierten la memoria en el cuello de botella.

Ese último punto conviene retenerlo al planear una caja multimedia, porque el impulso de comprar más RAM "para Plex" está mal dirigido. Lo que un servidor multimedia quiere de verdad es una CPU o GPU con transcodificación por hardware, que nuestra guía de almacenamiento para Plex Media Server cubre junto al lado del almacenamiento. Para los que trastean: antes de gastar en memoria, mide la máquina bajo una carga realista con free -h o htop, y en ZFS revisa la tasa de aciertos del ARC con arcstat; una tasa que se mantiene alta con la caja ocupada significa que el caché va cómodo y más RAM aportaría poco, mientras que una tasa que se desploma bajo carga es la señal real para ampliar. Ese enfoque medido le gana cada vez a dimensionar por la capacidad del pool. La conclusión: financia VMs, contenedores y dedup con generosidad, y deja de preocuparte por la transcodificación y la capacidad en bruto.

Una nota rápida sobre ECC

Una aclaración evita una confusión común: cuánta RAM necesitas y si esa RAM debe ser ECC son dos preguntas separadas. La memoria ECC (código de corrección de errores) va de integridad de datos, corrige en silencio el ocasional bit volteado antes de que llegue a tus discos, no de capacidad ni de velocidad, así que añadir ECC no cambia las cifras de la tabla de arriba. El propio OpenZFS llama a ECC muy recomendada, no obligatoria, y las historias de terror específicas de ZFS son un mito. La versión corta y honesta: ECC vale la pena en un build cuya razón de existir son datos irremplazables, y es prescindible en una caja multimedia casual, pero desarrollamos el caso completo, y qué plataformas la soportan, en RAM ECC para NAS y ZFS. La conclusión: decide primero la cantidad según tu carga, y luego, por separado, si los datos justifican ECC.

Recomendación: qué comprar de verdad

Para un servidor de archivos simple, un destino de backup o una caja Time Machine, 4 a 8 GB son toda la historia, y en un equipo sellado la memoria de fábrica suele bastar. Para un servidor multimedia con unos pocos contenedores (Plex o Jellyfin más las apps auxiliares de siempre), 8 GB son el aterrizaje cómodo, y el dinero que meterías en más RAM rinde mejor en una CPU con transcodificación por hardware. Para un pool doméstico de TrueNAS o ZFS, arranca en 16 GB y sube a 32 GB solo cuando sumes muchos usuarios simultáneos o máquinas virtuales, ignorando la regla de 1 GB por TB salvo que actives la deduplicación a propósito, donde presupuestas unos 5 GB por TB en su lugar. Para un homelab que corre máquinas virtuales en Unraid o Proxmox, dimensiona la RAM sumando invitados y contenedores, lo que de forma realista significa 32 GB o más. En todos, un hábito le gana a cualquier regla: si la placa lo permite, compra un nivel más y deja un slot libre, y si no, arranca sensato y deja que el uso real, no un hilo de foro, te diga cuándo ampliar. Cuando tengas resuelta la memoria, contrasta los discos y el diseño del pool detrás contra modelos reales en nuestra base de datos de discos NAS, y dimensiona la capacidad en sí en la calculadora RAID.

Artículos relacionados

Guía de hardware para NAS 2026: qué mirar según el SO y el sistema de archivos

Requisitos de hardware de ZFS 2026: RAM, ECC, HBA y SLOG

RAM ECC para NAS y ZFS: ¿obligatoria o mito?

Unraid vs. TrueNAS vs. OpenMediaVault: la comparativa completa de sistemas NAS

Autoalojamiento en el NAS: reemplaza suscripciones cloud con tus propios servicios