El stack cloud ya tiene siete niveles, no solo IaaS, PaaS y SaaS
Todos los cursos siguen enseñando tres cajas: IaaS, PaaS, SaaS. El mercado dejó de parecerse a ese dibujo hace cosa de año y medio.
El diagrama viejo era bueno. Respondía bien a una pregunta: ¿qué parte del servidor es problema mío? Alquilas una máquina y es toda tuya. Subes código a una plataforma y casi todo es suyo. Compras software terminado y nada es tuyo.
Luego pasaron tres cosas. El centro del stack se plegó sobre sí mismo. La base de datos se convirtió en un mercado aparte por el que pasan miles de millones de dólares. Y apareció un nivel nuevo, uno que existe porque ahora los agentes de IA escriben código que tiene que ejecutarse en algún sitio.
Este es el dibujo que yo haría en su lugar. Dos stacks, no uno, y SaaS en ninguno de los dos.
Fíjate en que SaaS no está en ninguno de los dos stacks. Siempre fue el raro. SaaS es software que compras. Los demás son sitios donde ejecutas el software que escribiste tú. Meterlos en el mismo diagrama confundió a una generación de estudiantes.
Cambio uno: PaaS y las funciones se fundieron
La regla vieja era sencilla, y durante años fue cierta.
Una app PaaS es un programa que se queda encendido. Está ahí esperando. Pagas por hora, todo el día, también a las 3 de la madrugada cuando no hay nadie despierto. Piensa en una tienda que deja las luces puestas.
Una función no es un programa que se queda encendido. Se despierta cuando llega una petición, hace el trabajo y se vuelve a dormir. Pagas por petición. Piensa en una máquina de vending.
Entonces: caliente es pagar por hora, frío es pagar por petición. Dos opciones limpias.
Las dos se han movido, y desde lados opuestos.
Fluid compute de Vercel deja que una instancia atienda muchas peticiones a la vez, y te cobra la CPU solo mientras tu código se está ejecutando de verdad. Si tu código está ahí esperando a que responda una base de datos o un modelo de IA, el contador de CPU se para. Entre petición y petición no se cobra nada. Las tarifas son $0.128 por hora de CPU y $0.0106 por GB-hora de memoria. Eso es un proceso caliente y de larga vida, facturado como una función.
Desde el otro lado, Google Cloud Run coge un contenedor Docker normal, le da Linux completo, el lenguaje que quieras, hasta 32 GB de memoria y un timeout de 60 minutos, y aun así lo escala a cero. Eso es una factura con forma de función envolviendo un servidor de verdad.
Las mismas tres peticiones, facturadas de tres maneras. "¿Está caliente?" y "¿cómo me facturan?" eran una sola pregunta. Ahora son dos, y puedes tener cualquier combinación de las dos.
Cambio dos: "serverless" ya significa cuatro cosas distintas
Aquí es donde se tuercen casi todas las conversaciones. Alguien dice que el equipo se pasa a serverless, todo el mundo asiente, y tres meses después descubren que lo que eligieron no puede ejecutar un cron.
- Ejecuta
- Un manejador de petición corto cada vez
- Escala a cero
- Sí, del todo
- La trampa
- Los límites varían; las instancias calientes pueden conservar memoria y archivos temporales, pero no se garantiza su persistencia
- Ejecuta
- Imágenes de contenedor compatibles. Servicios de Cloud Run: hasta 32 GiB y 60 minutos de timeout por petición. Fargate tiene otros límites y admite tareas de larga duración.
- Escala a cero
- Cloud Run puede hacerlo automáticamente. Los servicios de Fargate necesitan una política explícita de escalado y una forma de volver a arrancar las tareas.
- La trampa
- Sigue siendo una sola región salvo que te montes más
- Ejecuta
- JavaScript o WebAssembly, en todas las ciudades a la vez
- Escala a cero
- Sí, y arranca en menos de un milisegundo
- La trampa
- Sin runtime completo de Node, y muy poco presupuesto de CPU
- Ejecuta
- Postgres, con el cómputo separado del almacenamiento
- Escala a cero
- El cómputo sí, el almacenamiento nunca
- La trampa
- Despertar lleva su tiempo, y los bytes se facturan mientras duerme
Los cuatro no son parientes cercanos. Los límites de las funciones dependen del proveedor. El límite de una hora de Cloud Run se aplica a las peticiones de sus servicios, no a todos los contenedores serverless ni a los trabajos en segundo plano. Un isolate en el edge arranca en menos de un milisegundo pero no ejecuta código Node normal. Una base de datos serverless manda a dormir su cómputo y te sigue cobrando los bytes que tiene en disco.
La próxima vez que alguien diga serverless, pregunta cuál de los cuatro. Con los límites es con lo que vas a convivir.
Cambio tres: el dinero se fue a la base de datos
Mientras internet discutía sobre Kubernetes, el capital de verdad se fue a otro sitio.
Databricks pagó unos 1.000 millones de dólares por Neon, una empresa que vende Postgres serverless, sobre unos 25 millones de dólares de ingresos anuales. Snowflake se llevó Crunchy Data por 250 millones, según lo publicado. Supabase pasó de una valoración de 2.000 millones a una de 5.000 en cuatro meses. Postgres llegó al 55,6% de uso en la encuesta de Stack Overflow de 2025, la base de datos más usada dos años seguidos.
Los precios cayeron con fuerza después. El almacenamiento de Neon bajó de $1.75 a $0.35 por GB-mes, un recorte del 80%, y el cómputo también bajó.
La razón está en ese último número. Más del 80% de las bases de datos nuevas de Neon las crearon agentes de IA, no personas, frente al 30% de un año antes. Un agente que levanta una base de datos de usar y tirar por cada tarea es un cliente muy distinto de la persona que entra a la consola una vez por trimestre. El Postgres que escala a cero existe porque existe ese cliente.
Y esto es un segundo stack, no un nivel del primero. Dónde se ejecuta tu código y dónde viven tus datos son dos compras distintas. El diagrama viejo no tenía casilla para una base de datos, así que a nadie le enseñaron a pensarlo así.
La trampa de mezclar los dos stacks
Elige cómputo serverless y una base de datos gestionada normal, y te encontrarás con esto el primer día de tráfico serio.
Postgres viene con 100 conexiones por defecto, y no hay código ingenioso que arregle esa aritmética. O pones un pooler en medio o te comes una caída.
Dos cosas más que conviene saber antes de fiarte del "escala a cero" en una base de datos. El almacenamiento no duerme: solo duerme el cómputo, y una base de datos en pausa sigue facturando cada byte que guarda. Despertar lleva tiempo: una base de datos dormida necesita un momento para volver, y ese momento se suma al arranque en frío que ya tenía tu función.
Y luego está la asimetría que decide cuánta paranoia hace falta. Irte de tu plataforma de hosting es más o menos una semana de trabajo. Irte de tu base de datos es mover terabytes, pagar por sacarlos y reescribir consultas para otro motor. Relájate con el lock-in de cómputo. Ten cuidado con el lock-in de datos.
El nivel nuevo: sandboxes para el código que escribe la IA
Esta es la categoría genuinamente nueva, y no existía cuando alguien dibujó el diagrama original.
Un agente de IA escribe código. Ese código tiene que ejecutarse. No puedes ejecutarlo en tu propio servidor, porque no lo escribiste tú y no sabes qué hace. Necesitas un ordenador desechable: una tarea, aislado del todo, a la basura después.
Eso ya es una categoría de producto con competencia de verdad. En abril de 2026 el SDK de agentes de OpenAI incorporó soporte de sandbox con siete proveedores gestionados de serie: Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop y Vercel. Docker sacó una función experimental de sandbox propia.
| Proveedor | Cómo se aísla | Sesión más larga | GPU | Arranque en frío |
|---|---|---|---|---|
| E2B | microVM Firecracker | hasta 24 horas | no | unos 90 a 200 ms |
| Modal | contenedor gVisor | sin límite fijado | sí, de T4 a B200 | sin publicar |
| Daytona | contenedor Sysbox | sin límite fijado | sí | unos 90 ms |
| Vercel Sandbox | microVM Firecracker | 45 min gratis, 24 h de pago | no | sin publicar |
| Cloudflare Sandboxes | contenedor en el edge | 30 minutos | no | sin publicar |
| Blaxel | microVM | sin límite fijado | no | unos 25 ms |
Cifras que dan los propios proveedores, y se mueven rápido.
Las diferencias no son cosméticas. Los límites de sesión van de 30 minutos a ninguno. Los arranques en frío, de unos 25 milisegundos a un par de cientos. Algunos te dan GPU y la mayoría no. El modelo de aislamiento también cambia: microVM a nivel de hardware como Firecracker en un extremo, aislamiento por contenedor en el otro. Si vas a ejecutar código en el que de verdad no confías, esa es la columna que hay que leer primero.
¿Por qué te importa esto si no construyes agentes? Por ese 80% de Neon. El consumidor de infraestructura cloud que más crece ahora mismo no es una persona. Todos los proveedores se están rediseñando alrededor de un cliente que aparece de golpe, trabaja noventa segundos y desaparece. Eso cambia los productos que te ofrecen, seas quien seas.
Cómo elegir: empareja la forma del trabajo con el nivel
Dos preguntas en vez de una. Primera, ¿qué forma tiene el trabajo? Segunda, y aparte, ¿dónde viven los datos?
Casi todos los equipos aciertan la primera pregunta por instinto y fallan la segunda por defecto, porque el diagrama viejo nunca les contó que había una segunda pregunta.
Lo que no cambió en absoluto
Dos cosas siguen siendo cosa tuya en todos los niveles, del bare metal al sandbox más nuevo.
Tu esquema y tus consultas. Ningún proveedor de ninguno de los dos stacks te va a arreglar un índice que falta. Una base de datos gestionada haciendo un escaneo secuencial sobre cuarenta millones de filas es una base de datos lenta. Casi todos los tickets de "nuestra base de datos gestionada va lenta" son en realidad una consulta que nadie ha mirado.
Tu factura. Todos los modelos de aquí tienen su manera de sorprenderte. Los servidores siempre encendidos te cobran mientras duermes. Las funciones cobran por petición, y las peticiones suman más rápido de lo que nadie espera. Kubernetes cobra $73 al mes por clúster de EKS antes de que arranque un solo contenedor, y sube a unos $438 si dejas que el clúster se quede atrás de versión. Las bases de datos serverless cobran por los bytes en reposo. Nadie te manda un correo de aviso.
El diagrama de tu presentación no está mal. Es que viene de un mercado más pequeño. Redibújalo con dos stacks y siete niveles, y las discusiones de tu equipo se acortan bastante.
Elegir el nivel correcto, y salir del equivocado, es buena parte de lo que hago: migraciones a AWS, pasos de Lambda a contenedores y auditorías de coste para equipos que se decidieron pronto y ahora lo están pagando. Si tienes esa decisión delante, hablamos.
Las páginas de precios y los informes enlazados respaldan las cifras citadas. Consulta por separado los límites de Cloud Run y Fargate. Para los límites actuales de sandboxes, revisa E2B, Modal, Daytona, Vercel Sandbox, Cloudflare Sandboxes y Blaxel. La tabla es una instantánea, no un benchmark que yo haya ejecutado ni una garantía del tiempo de arranque. Comprobado en septiembre de 2026, y este mercado se mueve rápido, así que verifica antes de comprometerte con nada.