CAPÍTULO 9 · El mismo proyecto llega a Azure
Empezar con una capacidad que podamos explicar
La experiencia del equipo con PostgreSQL Flexible Server aporta un punto de partida concreto: una configuración económica pudo atender cuatro dispositivos que enviaban información periódicamente. Ese resultado es valioso porque demuestra lo que funcionó en su contexto. Pero trasladarlo a otro proyecto exige entender qué tamaño tenían los mensajes, qué consultas se hacían y cuánto histórico se conservaba.
Separamos cómputo, memoria y almacenamiento para no confundir el SKU con los gigabytes de disco. Relacionamos el ritmo de ingesta con crecimiento, conexiones y latencia. El costo aproximado recordado por el autor sirve como referencia de experiencia; una nueva entrega necesita su propia cotización y una revisión de las condiciones del servicio.
La elección de capacidad queda ligada a mediciones, incluido el comportamiento del pool que estudiamos antes. Ahora tenemos recursos que alguien debe crear, configurar y mantener. Ese acceso de operación necesita permisos propios: no es el mismo rol que utiliza una persona dentro de SensorHub.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Capacidad que se comprueba
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Carga. Cuatro IoT y usuarios
- Flexible Server. Separa CPU memoria y disco
- Métricas. Mide créditos y latencia
- Decisión. Cotiza y ajusta con evidencia
01 / EL PROBLEMA
¿Para qué sirve?
La aplicación necesita una base administrada, pero el equipo no puede elegir capacidad solo por el precio ni sobredimensionar sin medir.
02 / COMPRENDER
El concepto, explicado
El autor relata buenos resultados con un servidor económico, 32 GiB de almacenamiento y cuatro dispositivos enviando información cada tres segundos. Es evidencia de su experiencia, no un benchmark general: importan tamaño del mensaje, índices, retención, concurrencia y consultas.
B1ms es un SKU Burstable con 1 vCore y 2 GiB de RAM; 32 GiB describe almacenamiento, no memoria. Confirma el nombre exacto en el portal: B1, B1s y B1ms no son nombres intercambiables entre App Service, VM y PostgreSQL.
Burstable trabaja con créditos de CPU y está orientado principalmente a cargas no productivas o de baja utilización. Que una carga concreta funcione no acredita capacidad o continuidad para otro cliente. Observa CPU Credits Remaining, memoria, I/O, conexiones, almacenamiento y latencias.
Los aproximadamente USD 16 mensuales mencionados son una referencia de experiencia del autor, sin región, fecha ni factura verificadas. Cotiza región, moneda, cómputo, almacenamiento, backups, alta disponibilidad y transferencia. No se presenta como tarifa vigente ni precio total garantizado.
Cuatro dispositivos con un envío cada tres segundos equivalen aproximadamente a 1,33 envíos por segundo y 115.200 envíos diarios si transmiten las 24 horas. Eso no fija el número de filas: un envío puede contener varias mediciones. La retención debe calcularse con el tamaño real más índices y crecimiento.
La red de PostgreSQL y las credenciales runtime se configuran aparte del App Service. Habilita únicamente las rutas necesarias, verifica TLS y aplica la separación de roles estudiada. No concedas administración a la cuenta web solo para resolver un error de permisos.
03 / CONSTRUIR
Implementación paso a paso
- Crear Azure Database for PostgreSQL Flexible Server en el entorno y región elegidos.
- Seleccionar versión de PostgreSQL y revisar SKU, almacenamiento, backups y cotización antes de confirmar.
- Configurar conectividad y TLS para el App Service; crear base y roles runtime/migración.
- Cargar DB_HOST, DB_NAME, DB_USER, DB_PASSWORD y DB_PORT en el entorno que usa esos nombres.
- Ensayar cuatro dispositivos y navegación concurrente; medir créditos, latencia y conexiones.
- Definir umbrales para escalar, retención y restauración antes de asumir compromisos de servicio.
04 / APLICAR
Ejemplo en SensorHub
# SQL de diagnóstico: ejecutar con la cuenta autorizada.
SHOW max_connections;
SELECT count(*) AS conexiones_actuales FROM pg_stat_activity;
SELECT pg_size_pretty(pg_database_size(current_database())) AS tamano_base;
# Estimación de tráfico, no prueba de capacidad:
# 4 dispositivos / 3 segundos = 1.333... envíos por segundo
# 4 * (86400 / 3) = 115200 envíos por día
# Filas/día = envíos/día * mediciones_por_envío
# Capacidad: medir datos + índices + retención + margen.Cómo leer el ejemplo
- Las consultas miden el servidor; no cambian permisos ni tamaño.
- El tráfico reportado no basta para calcular memoria o costo.
- La capacidad del pool debe caber en el límite real del servidor.
Error habitual
Confundir 32 GiB de disco con RAM, o convertir una experiencia de costo y carga en una garantía para todos los proyectos.
05 / PRACTICAR
Tu turno
Cada envío de los cuatro dispositivos contiene cinco mediciones. ¿Cuántas filas diarias habría si guardas una por medición?
Ver solución orientativa
115.200 envíos por día por 5 mediciones: 576.000 filas diarias. Mide tamaño e índices y define retención antes de proyectar almacenamiento.
06 / VERIFICAR
Cómo sabes que funciona
- SKU y almacenamiento están identificados por separado.
- La cotización tiene región, fecha y componentes.
- Hay un ensayo de carga y un plan de recuperación.
- Se supervisan créditos de CPU y conexiones.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 2026-10-12.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
IAM de Azure: quién puede operar cada recurso →Continuar en modo relato