Por más de diez años desarrollamos software con una idea casi automática en la cabeza: la memoria es barata y sobra.
Si una aplicación se comía demasiada RAM, la respuesta casi nunca era sentarse a optimizar de verdad. Simplemente escalábamos: más RAM en la instancia, una máquina más grande o unas cuantas réplicas extra. Optimizar en profundidad se convirtió en algo casi opcional, como un lujo de perfeccionistas.
Ese mundo se está terminando rápido.
El boom de la inteligencia artificial ha cambiado las reglas de la infraestructura de forma profunda y estructural. Y está trayendo de vuelta algo que llevaba años en segundo plano: la eficiencia real del software.
El boom de la IA y la nueva escasez de memoria
Todo empieza en la cadena de suministro del hardware.
Los grandes jugadores —Samsung, SK hynix, Micron— han desviado una porción cada vez mayor de su producción hacia HBM (High Bandwidth Memory), esa memoria ultrarrápida que necesitan las GPUs para entrenar e inferir modelos de IA a gran escala.
Resultado directo: menos wafers disponibles para la DRAM convencional, la que usamos en servidores y en casi todo lo demás.
Desde 2025 y entrando en 2026 hemos visto un shock de oferta brutal:
- Subidas trimestrales de precios de server DRAM que en algunos momentos han rondado el 50-90%.
- En términos anuales, muchos contratos corporativos han sufrido aumentos superiores al 100-170%.
- En la práctica, el coste efectivo de la memoria se ha duplicado o triplicado respecto a inicios de 2025 en no pocos casos.
Por primera vez en mucho tiempo, la memoria ha vuelto a ser un recurso que duele en la factura.
La factura indirecta que nos pasa la IA en la nube
El golpe no se queda solo en el hardware físico.
La demanda desbocada de infraestructura para IA está apretando al mismo tiempo:
- capacidad de fabricación,
- consumo eléctrico,
- disponibilidad de GPUs,
- espacio en data centers.
Los grandes proveedores de nube (AWS, Google Cloud, Azure) están empezando a trasladar parte de esa presión a sus precios.
Las instancias con GPU ya eran caras de por sí, pero ahora el efecto se filtra también a lo general. Hemos visto ya:
- subidas directas en bloques de capacidad GPU (alrededor del 15% en algunos servicios de ML),
- ajustes en servicios relacionados,
- y sobre todo, una clara pausa (o incluso reversión) en la tendencia histórica de precios bajando año tras año en la nube.
Durante mucho tiempo dimos por hecho que la infraestructura se abarataría casi por arte de magia con el tiempo. Esa certeza ya no es tan sólida.
Cuando ahorrar memoria deja de ser «micro-optimización»
Cuando cada gigabyte extra impacta directamente en el P&L (Ganancias/Pérdidas), optimizar memoria pasa de ser un detalle bonito a una decisión que mueve números reales.
Un ejemplo muy concreto: las bases de datos en aplicaciones web donde la lectura domina el workload.
Diferencias en el modelo de conexión que ahora sí importan
- MySQL (con su modelo thread-per-connection) suele quedarse en torno a ~256 KB por conexión en idle.
- PostgreSQL, al usar un proceso independiente por conexión, tiene un overhead base mucho mayor. En entornos reales, dependiendo de la config y el workload, es habitual ver varios megabytes por conexión.
Ese consumo extra viene de cosas como work_mem, buffers del backend, el stack del proceso, librerías cargadas, etc.
Cuando manejas cientos o miles de conexiones concurrentes, la diferencia se dispara.
Por eso en sistemas de alto tráfico casi siempre terminamos poniendo un pooler delante (PgBouncer, PgCat, etc.) para reducir drásticamente el número de procesos reales activos.
No se trata de decir que una base de datos es «mejor» que otra en abstracto. El punto es que las decisiones de arquitectura ahora tienen un coste económico mucho más visible y directo.
Estrategias prácticas para 2026: cómo estirar lo que tenemos
Si la infraestructura vuelve a encarecerse, las arquitecturas que consumen poco recuperan todo su valor.
1. Herramientas y lenguajes que sean livianos por diseño
Vuelve a importar elegir cosas con bajo footprint en reposo:
- Lenguajes compilados y eficientes como Go o Rust
- Servicios con runtime mínimo
- Bases de datos embebidas como SQLite cuando el escenario lo permite
SQLite en producción puede ser una opción excelente si:
- la carga es mayormente lectura,
- la escritura concurrente es baja o controlada,
- y valoras la simplicidad operativa por encima de todo.
En esos casos te quitas de encima todo el overhead de un servidor de base de datos dedicado.
2. FinOps que sea realmente ingeniería
Cuando el hardware base sube de precio, FinOps deja de ser solo «control de gastos» y se convierte en una disciplina técnica central.
El foco pasa a estar en optimización continua y proactiva:
- right-sizing serio de instancias,
- caza de recursos zombie,
- análisis profundo de desperdicio en contenedores, serverless, etc.
Herramientas como CloudZero, nOps, Cast AI o las propias recomendaciones automáticas de los clouds ayudan mucho a automatizar y a mantener el ritmo.
3. Imágenes de contenedores minimalistas y runtimes limpios
Reducir el tamaño de las imágenes no es solo por “tiempos de deploy más rápidos”. También baja el consumo en runtime y simplifica la vida.
Usar bases como Alpine, distroless o directamente scratch, junto con multi-stage builds y limpieza agresiva de capas, permite:
- eliminar dependencias innecesarias,
- reducir la superficie de ataque,
- y tener entornos mucho más predecibles y livianos.
Para terminar
Durante años, escribir software eficiente fue casi una cuestión de estilo: algo que molaba, que se veía bonito en el CV, pero que rara vez era obligatorio.
El ciclo que estamos viviendo —impulsado por la IA a una escala nunca vista— está cambiando eso de raíz.
La infraestructura ya no es «cada vez más barata».
La memoria ya no sobra.
Y cada decisión que tomamos en arquitectura tiene un impacto económico que ya no podemos ignorar.
En este contexto, el equipo o el desarrollador que sabe hacer mucho con poco no solo sobrevive: vuelve a ser valioso de verdad, estructuralmente valioso.
La eficiencia deja de ser un «nice to have» para convertirse otra vez en una ventaja competitiva dura.
Después de una década asumiendo recursos casi infinitos, estamos volviendo a un mundo donde saber optimizar bien es, literalmente, una forma de ganar dinero.
Y eso, aunque suene duro al principio, también es una gran oportunidad para los que disfrutamos resolviendo problemas de verdad.
¿Qué piensas tú? ¿Ya estás notando el impacto en tus facturas o proyectos? Me encantaría leer tu experiencia en los comentarios.