Rendimiento y Costo Total de Propiedad de Bases de Datos en la Nube e Infraestructura Local

José Antônio Elias da Silva Júnior; Manoel Flavio Leal

DOI: 10.22167/2675-6528-202603055

Artículo derivado del Trabajo de Conclusión de Curso (TCC), con contenido basado en el trabajo original del alumno y adaptado al formato editorial de la Revista E&S con el apoyo de la herramienta ResumeAI, solución de inteligencia artificial desarrollada por el Instituto Pecege para síntesis y organización textual.

Resumen

El presente estudio analizó el rendimiento de operaciones de bases de datos en infraestructuras de nube y locales, correlacionando el comportamiento técnico con la proyección del Costo Total de Propiedad. La investigación se caracterizó como un estudio cuantitativo y experimental, en el cual un sistema de pruebas sometió instancias aisladas de bases de datos a cargas progresivas de ejecución, midiendo el impacto de la latencia de red y del consumo computacional. Para el análisis financiero, se elaboró un modelo de inversiones y gastos operativos diluidos en un ciclo de treinta y seis meses. Los resultados técnicos revelaron que la acumulación de la latencia de internet causó una severa degradación del tiempo en las ejecuciones en la nube, a pesar de que la infraestructura remota operaba con alta ociosidad de procesamiento, registrando casi el 98% de inactividad de la CPU. En contrapartida, el entorno local obtuvo un rendimiento superior amparado por la comunicación de red casi instantánea. En el aspecto financiero, la consolidación de los costos demostró un empate empírico entre el modelo de adquisición física y el de suscripción de servicio en un horizonte de tres años, pero el entorno local se mostró más ventajoso en un ciclo de sesenta meses. Se concluyó que la degradación en la nube no provino de la capacidad computacional, sino de la interacción entre la latencia de ruta y el patrón de comunicación unitario de la aplicación. La adopción de la nube exige una optimización profunda de la arquitectura del sistema para minimizar la dependencia de comunicación constante con el servidor remoto. Sin esta modernización, la infraestructura local se consolidó como la estrategia más viable, garantizando alto rendimiento, previsibilidad presupuestaria y soberanía de los datos.

Palabras clave: Gastos operativos (OPEX); Escalabilidad transaccional; Latencia de red; Sistemas heredados.

1. Introducción

La evolución de la tecnología de la información ha estado marcada por una transición significativa en los modelos de infraestructura. Históricamente, las organizaciones dependieron de arquitecturas locales que, a pesar de ser ampliamente utilizadas, presentaron complejidades inherentes y altos costos asociados al mantenimiento de una estructura propia. Más recientemente, el paradigma de la computación en la nube surgió como una alternativa escalable para la externalización de la gestión de esta infraestructura.

La decisión entre adoptar una infraestructura en la nube o mantener una estructura local se ha convertido en un dilema central para las empresas de software modernas, lo que exige la reevaluación de repositorios y arquitecturas tradicionales frente a las nuevas demandas tecnológicas (Noor et al., 2024). Desde el punto de vista financiero, estudios como el de Kumar (2024) indicaron que la migración a la nube puede generar ahorros del 30% al 40% en los costos de infraestructura en escenarios específicos. Sin embargo, para aplicaciones sensibles al tiempo de respuesta de la red (latencia), las implementaciones locales demostraron alcanzar un rendimiento hasta un 42% superior (Kumar, 2024), lo que creó una compleja relación de intercambio entre costo y velocidad.

En la práctica operativa, la búsqueda de la mejor relación costo-beneficio revela que la elección entre modelos va mucho más allá de la simple asignación de servidores. Mantener una infraestructura local exige una alta inversión inicial (gasto de capital), pero puede resultar financieramente ventajosa y predecible a largo plazo. Además, el mantenimiento de servidores propios garantiza la soberanía total sobre el tráfico de datos, un factor crucial en operaciones de alto volumen como conversiones masivas de bases de datos durante la migración entre sistemas (Holmnäs, 2024). Por otro lado, muchas organizaciones han fallado al migrar a la nube por ignorar los “costos ocultos” de rendimiento. Una aplicación heredada, originalmente optimizada para redes locales, puede volverse prohibitivamente cara en la nube debido a la necesidad de aumentar el consumo de recursos computacionales (medidos comercialmente en vCores o DTUs) solo para compensar ineficiencias de código y el retraso en la comunicación de red.

Investigaciones recientes en arquitectura de sistemas han desplazado el foco de la capacidad de procesamiento al costo de la comunicación entre componentes. Zhang et al. (2025) demostraron que, en bases de datos con almacenamiento desagregado, la latencia del acceso remoto se convierte en el factor dominante de degradación. Xu et al. (2025) identificaron la sincronización entre nodos geográficamente distribuidos como el principal cuello de botella en redes de larga distancia. La literatura comparativa entre la nube y la infraestructura local, sin embargo, se centra ora en la agregación de costos (Pillai, 2024), ora en el rendimiento de la infraestructura aislada (Husain et al., 2024), sin separar el esfuerzo computacional del motor de base de datos y la espera impuesta por el patrón de comunicación de la aplicación. Permanece así indeterminado si la lentitud atribuida a la nube se debe a la ubicación remota de la base de datos o a la arquitectura de acceso, una distinción con consecuencias opuestas.

Queda en evidencia, por lo tanto, que no existe una solución definitiva o generalizable para todas las empresas; cada contexto exige un análisis criterioso. Ante este escenario, este trabajo se justifica por la necesidad de proporcionar datos empíricos que auxilien a los gestores a dirigir sus estrategias tecnológicas de forma asertiva. El presente estudio tiene como objetivo analizar la capacidad y el desempeño de operaciones de bases de datos en ambas infraestructuras, correlacionando estas métricas técnicas con el Costo Total de Propiedad. La finalidad central no es señalar una tecnología como superior en carácter absoluto, sino explorar sus ventajas y desventajas a partir de datos empíricos, culminando en la elaboración de una matriz de decisión que auxilie a los gestores a dirigir sus estrategias tecnológicas de forma asertiva.

2. Material y Métodos

El presente estudio se caracterizó como una investigación de enfoque estrictamente cuantitativo y de diseño experimental. El objetivo central del experimento fue someter infraestructuras de bases de datos, ubicadas en medios físicos distintos, a cargas transaccionales progresivas. Se midió el impacto de la latencia de red y la capacidad de procesamiento interno de cada ambiente, con el fin de correlacionar estas métricas técnicas con el Costo Total de Propiedad, conforme al objetivo general establecido.

Para asegurar la validez empírica del estudio, el diseño se centró en el aislamiento de variables. Se garantizó que el esfuerzo computacional del motor de la base de datos pudiera separarse cronométricamente del tiempo requerido para el transporte de paquetes a través de Internet pública y la red local. La arquitectura del experimento fue estrictamente segregada, separando el entorno de desarrollo del entorno de ejecución, y la topología de la prueba consistió en tres instancias independientes y aisladas.

La primera instancia operó como Máquina Cliente, configurada como una máquina virtual dedicada. Ejecutaba el sistema operativo “Windows 10”, aprovisionada con 4 GB de memoria RAM y 2 núcleos lógicos de procesamiento, basados en la arquitectura AMD Ryzen 5 5500U. Este entorno fue responsable exclusiva y únicamente de ejecutar la aplicación de medición de rendimiento, sin la presencia de herramientas de desarrollo pesadas en segundo plano.

La segunda instancia representó el entorno físico corporativo, denominado “On-Premise”. Fue configurada como una máquina virtual bajo el sistema operativo “Windows Server”, poseyendo especificaciones de hardware idénticas a la máquina cliente, dedicada a alojar el motor de base de datos “SQL Server 2019 Express”. Para garantizar la fidelidad del escenario local, los adaptadores virtuales de red de ambas máquinas fueron configurados en modo puente (“Bridge”).

Con esta parametrización, cada instancia operó de forma autónoma en la infraestructura, recibiendo direcciones IP independientes asignadas por el router físico. La comunicación ocurrió a través del tráfico real de paquetes del protocolo TCP/IP por la red local (LAN). Este aislamiento impidió el uso de conexiones de bucle de retorno, lo que invalidaría la medición precisa de la latencia característica de una red corporativa física.

La tercera instancia de la topología representó el entorno remoto en la nube, denominado “Cloud”. Estuvo constituida por una base de datos “Azure SQL Database”, aprovisionada en el modelo de compra basado en núcleos virtuales (“vCore”), asignada bajo la capa de servicio de Uso General. La computación se configuró en el modo “Serverless”, utilizando la generación de hardware estructural “Standard-series (Gen 5)”.

El escalado dinámico del procesamiento se limitó a operar con un mínimo de 0,5 y un máximo de 2 “vCores”. Esta configuración se eligió intencionalmente para representar una línea de base de entrada, reflejando el escenario inicial de adopción por parte de empresas reales que buscan validación de concepto o elasticidad de costos.

El motor de pruebas de estrés consistió en una aplicación de consola desarrollada en el lenguaje C# y compilada sobre la plataforma .NET 8.0. El acceso a los datos y la comunicación transaccional entre la aplicación cliente y las dos instancias de bases de datos fueron intermediados por el mapeador objeto-relacional de bajo nivel Dapper (DAPPERLIB, 2024).

La elección de Dapper se justificó por su altísimo rendimiento. Al realizar el mapeo directo de instrucciones nativas a objetos en memoria, Dapper eliminó la sobrecarga de traducción de consultas, añadiendo el menor tiempo de procesamiento posible a la conversión de datos.

Un factor metodológico crítico para la validez del experimento fue la estandarización rigurosa de la masa de datos y de los paquetes de tráfico de red (“payloads”). La estructura de las tablas y los datos sintéticos generados en memoria se dimensionaron con tamaños fijos y rellenos de caracteres rigurosamente idénticos. Para mitigar este riesgo, se utilizó la biblioteca de generación de datos “Bogus” (BOGUS, 2024).

Este enfoque aseguró que cada paquete TCP/IP enviado del cliente al servidor, independientemente de si se encontraba en el entorno local o en la nube, tuviera exactamente el mismo peso en bytes. Esto aisló la latencia de ruta como la única variable temporal del experimento, eliminando cualquier posibilidad de sesgo en los resultados debido a discrepancias en el volumen de información transmitida en cada iteración.

Para evitar ambigüedad en la lectura de los resultados, se adoptó una definición operacional estricta del término transacción. Cada transacción correspondió a un único comando enviado individualmente al banco bajo confirmación automática, lo que equivale a un único ida y vuelta de red. No se utilizaron bloques transaccionales explícitos agrupando múltiples comandos.

Así, “carga de 128 transacciones” designó 128 comandos independientes, sometidos secuencialmente, cada uno esperando la confirmación del anterior. Este patrón es predominante en los sistemas heredados orientados a registro, que constituyeron el objeto de esta investigación. La composición de cada operación, incluyendo el comando sometido, las validaciones relacionales exigidas del motor y el número de idas y vueltas por unidad de carga, fue detallada.

En todas las operaciones, el campo de descripción se rellenó con exactamente 5.000 caracteres, de modo que el paquete transferido tuviera un peso idéntico en ambos entornos. En las modificaciones y exclusiones, la consulta previa se ejecutó una sola vez por lote, fuera del cronómetro, de forma que el tiempo medido correspondió estrictamente a las escrituras unitarias.

Para simular el esfuerzo de procesamiento coherente con aplicaciones de negocio del mundo real, la tabla principal (“TransaccionFinanciera”) fue modelada con fuertes ataduras relacionales. El algoritmo generó identificadores numéricos que actúan como claves foráneas para las tablas de Usuario, Categoría y Banco. Este modelado garantizó el respeto a las propiedades ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad).

La estrategia de pruebas evaluó las tres operaciones fundamentales de persistencia en base de datos: Inserción, Modificación y Exclusión. Para simular escenarios operacionales reales y mantener la isonomía de la prueba, las operaciones de modificación y exclusión no se ejecutaron de forma ciega, siguiendo el patrón arquitectural de búsqueda y procesamiento (“fetch and process”).

En primer lugar, la aplicación realizaba una consulta compleja que devolvía de forma determinista los identificadores a manipular. A continuación, la sumisión de las solicitudes de cambio se producía de forma unitaria dentro de bucles de repetición. Las baterías de pruebas obedecieron a un crecimiento geométrico en potencias de base dos.

Cada ciclo iniciaba la ejecución con una única operación unitaria, doblando la carga sucesivamente (2, 4, 8, 16, 32 y 64), hasta alcanzar el límite de saturación estipulado en 128 transacciones secuenciales. Para la orquestación de la recolección y la extracción estadística, se utilizó la biblioteca de precisión “BenchmarkDotNet” (BENCHMARKDOTNET, 2024).

Cada escenario geométrico se repitió íntegramente cuatro veces para cada operación, atestiguando que el comportamiento de la infraestructura no poseía carácter puntual o aleatorio. Se adoptó una precaución arquitectónica vital en relación con el fenómeno de Arranque en Frío (“Cold Start”), intrínseco a las arquitecturas “Serverless” y a la compilación Just-In-Time de .NET.

Antes de activar el cronómetro oficial de cada batería, el método de preparación global de BenchmarkDotNet ejecutaba rutinas de calentamiento natural. Estas rutinas consistían en abrir previamente las conexiones a la base de datos, realizar consultas de recuento y reponer masas de datos agotadas. Este control aseguró la asignación dinámica de los vCores en la nube, el establecimiento de la agrupación de conexiones activas y la carga de los índices en la memoria RAM.

Con esta mitigación, se garantizó que la telemetría final capturara estrictamente el costo de la latencia de transporte, eximiendo la medición del tiempo letárgico de despertar de la infraestructura en la nube. Para garantizar la reproducibilidad del experimento, la arquitectura de software desarrollada para la medición de los tiempos de respuesta fue aislada en clases específicas, utilizando los atributos de la biblioteca BenchmarkDotNet.

La clase de actualización, denominada “UpdateBenchmark”, fue desarrollada para medir los tiempos de respuesta, incorporando atributos de la biblioteca BenchmarkDotNet para el control de la masa de datos y la mitigación del fenómeno de Arranque en Frío. El método de preparación global verificaba el recuento de transacciones activas en la base de datos antes del cronómetro oficial.

La ejecución de las instrucciones de la base de datos fue delegada al paquete Dapper, con la instrucción de actualización parametrizada y enviada de forma unitaria por el comando “Execute()”, confirmando el modelo de prueba “línea a línea”. El algoritmo de generación de datos sintéticos, implementado con la biblioteca Bogus, no fue puramente aleatorio, sino contenido en parámetros restrictivos. El campo de descripción fue instruido a crear secuencias alfanuméricas con exactamente 5.000 caracteres, asegurando que cada paquete TCP/IP tuviera el mismo peso en bytes.

Para garantizar la repetición de las baterías de exclusión manteniendo el rigor estadístico sin la necesidad de recrear la infraestructura en cada ciclo, se desarrolló un algoritmo de reposición diferencial (“ReporMassaDiferencial”), integrado al ciclo de vida de la biblioteca de “benchmark”. Antes de iniciar el cronómetro para medir el tiempo de exclusión, el método “Setup” realizaba un conteo activo de registros.

Al identificar que el volumen de la tabla estaba por debajo del umbral preestablecido de diez mil registros, el sistema calculaba dinámicamente la diferencia exacta y solicitaba al repositorio la inserción de la cantidad faltante. Este mecanismo operó como un estabilizador de estado, garantizando que todas las rondas de validación de la operación de exclusión encontraran la base de datos en las mismas condiciones volumétricas y de fragmentación de índices.

Para el análisis financiero, se elaboró una proyección de Costo Total de Propiedad (TCO) para un ciclo de vida inicial de treinta y seis meses. La elección de este período se fundamentó en las prácticas contables estándar para la depreciación de activos de tecnología. Se utilizó la metodología matemática del Costo Mensual Equivalente, que diluye la inversión de capital a lo largo de los meses de operación, sumándola a los gastos operativos recurrentes.

La composición de la inversión inicial y los gastos operativos, incluidos los costos de infraestructura de hardware, la tarificación de la energía eléctrica, la fijación de precios de servicios en la nube y el alquiler de propiedades, se basó en datos de mercado (DELL, 2026; ENEL, 2026; MICROSOFT, 2026; QUINTOANDAR, 2026).

3. Resultados y Discusión

El análisis de los datos empíricos recopilados durante el experimento reveló insights cruciales sobre el rendimiento y el costo de las operaciones de bases de datos en infraestructuras de nube y locales. El objetivo central fue ir más allá de la mera presentación de métricas, promoviendo una discusión crítica sobre cómo la elección de la infraestructura impacta el comportamiento transaccional de la base de datos y, consecuentemente, la viabilidad financiera y arquitectónica de los proyectos. Los resultados se estructuraron para responder progresivamente a las hipótesis iniciales del estudio, confrontando los hallazgos de laboratorio con la literatura académica reciente para validar las conclusiones propuestas.

La evaluación técnica se realizó mediante un riguroso proceso de telemetría, que capturó el tiempo de respuesta y el consumo de recursos físicos bajo cargas progresivas de solicitudes. Al someter los motores de base de datos a ciclos de ejecución que variaban desde transacciones unitarias hasta lotes intensivos de 128 operaciones, fue posible aislar el esfuerzo computacional real del motor de datos del tiempo necesario para el transporte de paquetes. Esta segregación fue fundamental para identificar si los cuellos de botella eran limitaciones físicas de hardware o restricciones impuestas por la topología de la red, permitiendo una comprensión más profunda de los fenómenos observados.

Análisis de Latencia Transaccional en Entorno de Nube

La evaluación técnica de rendimiento en el entorno de nube, sometida a cargas unitarias y progresivas (de 1 a 128 transacciones), reveló un fenómeno empírico notable: la alta latencia de la red ofuscó las diferencias de tiempo de procesamiento que normalmente existirían entre las operaciones de Inserción, Modificación y Eliminación. El entorno en la nube presentó curvas de tiempo virtualmente superpuestas para estas operaciones. Este comportamiento indicó que el procesamiento interno del motor de base de datos consumió una fracción ínfima del tiempo total en comparación con el tiempo de comunicación remota, resultando en una demora cercana a 2.600 milisegundos en la carga máxima de 128 transacciones.

La casi totalidad del tiempo medido en este escenario provino del tránsito de paquetes (ida y vuelta) en la red pública. Este comportamiento empírico encuentra un fuerte respaldo en la literatura contemporánea, donde Cho’ponov (2026) identifica una “tasa de latencia” estructural e inevitable, estipulada entre 10 y 50 milisegundos por salto de red. Verbitski et al. (2017) también señalan que la restricción central del procesamiento de alto rendimiento se ha desplazado de la computación y el almacenamiento a la red. Dividiendo el tiempo total de la carga máxima del experimento (aproximadamente 2.500 milisegundos) entre las 128 iteraciones sometidas, se observó una latencia media de 19,5 milisegundos por operación en la nube, valor que se alinea a la franja crítica de degradación prevista para entornos remotos.

Un factor técnico que contribuyó activamente al apilamiento del tiempo observado fue la naturaleza del protocolo de comunicación utilizado por el motor de base de datos, el “Tabular Data Stream” (TDS). Husain et al. (2024) destacan que, en soluciones de Microsoft SQL Server que operan como servicio, cada solicitud unitaria requiere una confirmación de recepción (“acknowledgment”) antes de que la siguiente instrucción del código sea procesada. En redes locales, este tiempo de ida y vuelta es despreciable, pero en la nube, el tiempo empleado en el encapsulamiento de paquetes y en la transposición de rutas de larga distancia se convierte en el componente mayoritario de la operación, eclipsando la real capacidad de procesamiento de la plataforma.

Desde la perspectiva de la ingeniería de software distribuido, Yang et al. (2023) explican que esta lentitud no es un fallo de configuración, sino el precio arquitectónico exigido para mantener la fuerte consistencia de los datos. Según el Teorema CAP, al particionar el sistema a través de Internet, la base de datos remota debe garantizar que cada instrucción de escritura se consolide en los nodos de almacenamiento antes de responder con éxito a la aplicación cliente. En consecuencia, el código del sistema se ve obligado a esperar la confirmación del tránsito en cada repetición del bucle, generando el severo efecto de acumulación temporal observado.

Análisis de Latencia Transaccional en Entorno Local (“On-Premise”)

En contraste con el escenario remoto, el análisis del entorno local corroboró la premisa de la investigación desde una óptica inversa. Libre de la penalización de tráfico de larga distancia, la infraestructura local no solo respondió de manera sustancialmente más rápida, finalizando el lote máximo de 128 transacciones en el rango de 250 a 410 milisegundos, sino que también reveló el verdadero costo computacional de cada operación. En el escenario aislado de latencia de red casi nula, se hizo posible notar visualmente el distanciamiento de la curva de Exclusión en relación con la Inserción, un comportamiento que antes estaba enmascarado por la espera exógena en internet.

La visibilidad sobre el esfuerzo interno del motor de base de datos es validada por Cho’ponov (2026), quien argumenta que la proximidad física entre la aplicación y el servidor elimina la carga adicional de red, permitiendo que la infraestructura entregue su rendimiento nominal total. Mientras que en la nube la latencia consume la mayor parte del tiempo de ejecución, en el entorno local el tiempo medido es una representación fiel de la eficiencia algorítmica y de la velocidad de escritura en disco. Conforme observado en el experimento, la ausencia de saltos externos permitió una reducción de aproximadamente el 90% en el tiempo total de ejecución para la carga de 128 transacciones.

Adicionalmente, Husain et al. (2024) refuerzan que las soluciones locales de Microsoft SQL Server ofrecen una previsibilidad de procesamiento que es difícil de replicar en entornos de base de datos como servicio sin inversiones masivas en capas de hardware redundantes. Los datos recopilados demuestran esta estabilidad, en la cual el crecimiento del tiempo de respuesta ocurre de forma lineal y estrictamente proporcional al aumento de la carga. No se observan las fluctuaciones y picos de espera característicos del tráfico vía internet pública, lo que garantiza una ejecución constante independientemente de factores externos de conectividad. Este factor es identificado por Pillai (2024) como crítico para sectores que operan con volúmenes masivos de datos y exigen baja latencia operacional como requisito de negocio innegociable.

Análisis Comparativo Global e Impacto na Experiência do Usuário

La magnitud de la penalización impuesta por el modelo de solicitudes unitarias a la infraestructura en la nube se hace categóricamente evidente al consolidar el promedio global de las operaciones. Se observa un distanciamiento inmediato de las curvas de rendimiento desde el primer ciclo de carga. En la transacción unitaria (1 ciclo), la arquitectura local procesó la solicitud en un promedio inferior a 7 milisegundos, mientras que la nube demandó aproximadamente 50 milisegundos, una diferencia inicial que establece el nivel de eficiencia de cada entorno. Este distanciamiento no es un evento aislado, sino la materialización empírica de lo que Cho’ponov (2026) define como “tasa de latencia”.

El autor argumenta que la transformación de simples llamadas internas de sistema en peticiones de red externa inserta un coste temporal que se acumula progresivamente con cada nuevo salto de red. Como el código sometido a prueba ejecuta iteraciones repetitivas, esta latencia inicial de 50 milisegundos se multiplicó a lo largo del bucle de ejecución, resultando en el abismo de rendimiento observado en el límite de carga de 128 transacciones. Desde el punto de vista estratégico y de negocio, esta degradación temporal compromete directamente el “rendimiento percibido por el usuario” (Järvinen, 2025), que destaca la insatisfacción del usuario final cuando la arquitectura del software exige múltiples viajes de ida y vuelta al servidor remoto para completar una única tarea lógica.

Los datos validan la tesis de que la migración de una aplicación a la nube sin la debida refactorización para minimizar el diálogo constante con la base de datos resultará en lentitud crónica, independientemente del poder de procesamiento contratado. Este escenario ilustra con exactitud el riesgo asociado a la estrategia de migración conocida como transferencia directa (“Lift-and-Shift”). Kansara (2024) advierte que la simple transposición de sistemas locales a la nube, sin la previa adecuación de la arquitectura de comunicación, frecuentemente transforma la elasticidad de la infraestructura en la nube en un cuello de botella operativo insostenible. Un código heredado que asume la latencia de una red local, al operar en internet público, hace que el sistema sea técnicamente ineficiente y financieramente arriesgado.

Análisis de Uso de CPU y Ociosidad

Más allá de la degradación temporal, la viabilidad técnica y financiera de una arquitectura de base de datos está directamente ligada a la eficiencia en el consumo de recursos, especialmente el procesamiento computacional. La telemetría durante la ejecución de la carga máxima (128 transacciones) reveló que el entorno local empleó en promedio el 14,2% de la capacidad de su procesador, mientras que el servidor remoto en la nube operó con una tasa de inactividad cercana al 98%, consumiendo solo el 1,3% de CPU. Esto desmitifica la hipótesis de que la lentitud de la nube estaría asociada a un agotamiento de su capacidad computacional.

El consumo de solo el 1,3% de CPU en la nube demuestra que la base de datos resolvía la solicitud de escritura o lectura en fracciones de milisegundo, y pasaba el resto de los 2,5 segundos de la prueba en estado de absoluta inactividad, solo esperando la llegada del próximo paquete a través de Internet. Desde la perspectiva de la ingeniería de software de la arquitectura de Microsoft SQL Server, esta subutilización revela que la plataforma pasó la mayor parte del tiempo de ejecución atascada en el evento de espera (“wait type”) conocido técnicamente como “ASYNC_NETWORK_IO”. Este evento ocurre cuando el motor de la base de datos finaliza el procesamiento interno de forma casi instantánea, pero se ve obligado a suspender la operación porque la aplicación cliente, separada por la latencia de la red pública, tarda en consumir los datos o en enviar la siguiente instrucción.

Este hallazgo corrobora los análisis de Husain et al. (2024), quienes observan que el aprovisionamiento de hardware en soluciones de base de datos como servicio (DBaaS) frecuentemente se vuelve subutilizado debido a severos cuellos de botella externos de entrada y salida (I/O) de red. En contrapartida, la infraestructura local, con latencia ínfima en la red local (LAN), permitió que los paquetes llegaran ininterrumpidamente, haciendo que la base de datos trabajara en flujo continuo. Sin el bloqueo del “ASYNC_NETWORK_IO”, el servidor físico finalizó todo el bloque de operaciones rápidamente, justificando el uso pleno del recurso adquirido y demostrando una eficiencia arquitectural superior para sistemas de peticiones secuenciales.

Desde el punto de vista financiero, esta inactividad en la nube se traduce en un severo costo oculto. Brown (2025) destaca que las arquitecturas sin servidor (“Serverless”), como la edición de Azure SQL Database utilizada en este experimento, se comercializan bajo la promesa de cobro granular y alta eficiencia financiera. Sin embargo, la autora advierte sobre los compromisos (“trade-offs”) generados cuando el código no está optimizado para este modelo de tarificación. Dado que la factura en la nube se calcula por tiempo de computación activa (facturada al segundo), la sumisión de iteraciones unitarias fuerza a la base de datos a permanecer con la sesión abierta durante largos períodos para resolver un volumen de trabajo ínfimo. Se valida, por lo tanto, la tesis de Brown (2025): el modelo de tarificación bajo demanda se vuelve altamente oneroso si la aplicación no utiliza procesamiento por lotes (“batch processing”), transformando la inactividad forzada por la red en un pasivo financiero directo para la organización.

Descomposición del Tiempo entre Procesamiento y Espera

Establecida la diferencia de rendimiento, la investigación buscó responder a una cuestión causal fundamental: ¿la degradación se deriva de la ubicación remota del banco o de la arquitectura de comunicación de la aplicación? Para resolver la cuestión, el tiempo total se descompuso en dos partes mutuamente excluyentes: el tiempo en que el motor estuvo efectivamente procesando, obtenido por el producto entre el tiempo total y el porcentaje medio de utilización del procesador medido por telemetría, y el tiempo residual de espera por comunicación. En la carga de 128 transacciones, el tiempo de procesamiento efectivo se mantuvo en el mismo orden de magnitud en ambos entornos, con 44,0 milisegundos en el servidor local frente a 33,2 milisegundos en la instancia remota.

El resultado es concluyente: en el trabajo computacional realizado, la base de datos en la nube no fue más lenta que la local. La totalidad de la diferencia se concentra en la porción de espera, que pasó de 266,0 milisegundos en el entorno local a 2.516,8 milisegundos en la nube. Se concluye que la infraestructura remota no constituye, por sí sola, la causa de la degradación. El factor determinante es la interacción entre la latencia de ruta, que fija el costo de cada ida y vuelta, y el patrón de comunicación unitario de la aplicación, que determina cuántas idas y vueltas ocurren. La latencia actúa como multiplicador y la arquitectura, como amplificador; aisladamente, ninguna de las dos explica el resultado.

Un segundo hallazgo refuerza esta interpretación: la relación entre los tiempos de la nube y del entorno local se mantuvo prácticamente constante en toda la escala, desde la transacción unitaria hasta el lote de 128. Si la degradación proviniera del agotamiento de la capacidad contratada, se esperaría una relación creciente, con un alejamiento progresivo de las curvas. La constancia indica una penalización multiplicativa y estructural, proporcional al número de idas y vueltas, y no una saturación de recursos. La descomposición permite estimar el efecto de una alteración arquitectónica que preservara la infraestructura contratada: sustituyendo las 128 idas y vueltas unitarias por una única sumisión en lote, el tiempo esperado en la nube sería del orden de 53 milisegundos, frente a los cerca de 2.550 medidos. Se trata de una proyección analítica derivada de los datos recopilados, y su orden de magnitud sustenta la tesis de que la nube no fue lenta, sino que la aplicación fue conservadora.

El hallazgo dialoga con la literatura reciente. Zhang et al. (2025) observaron que, en almacenamiento desagregado, la latencia del acceso remoto se superpone a la capacidad de procesamiento, penalizando sobre todo las escrituras, comportamiento idéntico al aquí medido. Xu et al. (2025) demostraron que el cuello de botella de bancos geográficamente distribuidos reside en la sincronización sobre redes de larga distancia, y no en el procesamiento de cada nodo. La convergencia indica un fenómeno estructural de las arquitecturas distribuidas, donde la latencia de red y el patrón de comunicación de la aplicación interactúan para determinar el rendimiento.

Regímenes de Carga y Superioridad Contextual de Cada Arquitectura

Una vez establecida la causa de la degradación, fue posible calificar en qué contextos cada arquitectura es superior. La descomposición permite clasificar cualquier carga según la porción dominante de su tiempo de ejecución. Se denomina régimen limitado por red aquel en el que la espera por comunicación supera el procesamiento efectivo, observado en ambos entornos de este experimento. En él, el rendimiento está gobernado por el producto entre la latencia de ruta y el número de idas y vueltas, y contratar más capacidad no produce una ganancia apreciable, ya que el recurso adicional permanece ocioso a la espera. Este régimen es característico de sistemas transaccionales unitarios y heredados, donde se recomienda la infraestructura local debido a que el tiempo está gobernado por el número de idas y vueltas.

Se denomina régimen limitado por procesamiento aquel en el que el esfuerzo computacional supera el tiempo de comunicación. Las cargas analíticas y los procesamientos por lotes entran en esta categoría, ya que amortizan una única latencia de ruta sobre un volumen elevado de trabajo. Aquí, la elasticidad de la nube se convierte en una ventaja efectiva, y el entorno local es penalizado por el techo rígido del hardware adquirido. La implicación práctica es que la elección de infraestructura no debe preceder a la caracterización del régimen predominante de la aplicación. Se elaboró una matriz de decisión para consolidar este análisis, recomendando la nube para procesamiento por lotes, cargas analíticas, demandas estacionales con picos pronunciados y aplicaciones refactorizadas para envío agrupado, donde una latencia de ruta se amortiza sobre un gran volumen o se evita la ociosidad del activo.

La matriz de decisión también indica el entorno local para volúmenes constantes en ciclo largo y la exigencia de soberanía sobre los datos, ya que el tráfico interno no se tarifa y no hay terceros involucrados. La matriz evidencia que ninguna arquitectura es superior en carácter absoluto; la superioridad es contextual y determinada por el régimen de carga, premisa ya sustentada por Tan et al. (2019) al demostrar que la elección de una base de datos en la nube depende del acoplamiento entre la arquitectura y el perfil de la carga, y no de un ordenamiento único de desempeño. El equívoco recurrente en las migraciones consiste en transponer a la nube una aplicación limitada por red sin alterar su patrón de comunicación, pagando por la elasticidad sin poder consumirla, lo que converge con la advertencia de Kansara (2024) sobre la transferencia directa de sistemas legados.

Descomposición del Costo Total de Propiedad [TCO]

Para cuantificar el impacto financiero de la elección de la arquitectura y materializar los efectos de la latencia, se elaboró una proyección de Costo Total de Propiedad (TCO) para un ciclo de vida inicial de treinta y seis meses. La elección de este período se fundamenta en las prácticas contables estándar para la depreciación de activos de tecnología. Para viabilizar una comparación equitativa entre el modelo de adquisición de infraestructura física local y el modelo de suscripción de servicios en la nube, se utilizó la metodología matemática del Costo Mensual Equivalente, que diluye la inversión de capital (CAPEX) a lo largo de los meses de operación, sumándola a los gastos operativos recurrentes (OPEX).

La proyección del Costo Mensual Equivalente reveló un empate técnico y una estricta paridad financiera en el escenario a tres años, con el entorno local costando R$ 2.233,30 y la suscripción a la nube R$ 2.216,00. Este hallazgo empírico contradice gran parte del sentido común del mercado tecnológico, que frecuentemente asocia la adopción de la computación en la nube con una reducción drástica y automática en los gastos de infraestructura. Leis y Kuschewski (2021) demuestran, en el mismo sentido, que el rendimiento y el costo en la nube varían en órdenes de magnitud según la configuración contratada, de modo que no hay ahorro disociado del dimensionamiento.

Pillai (2024), al analizar estrategias de almacenamiento y procesamiento de datos en instituciones financieras y sectores tradicionales, argumenta que los costos de infraestructura local, aunque exigen una elevada inversión inicial de capital, se amortizan de forma altamente predecible y segura a largo plazo. Los datos validan la tesis de Pillai, demostrando que, al diluir criteriosamente los gastos eléctricos, inmobiliarios y de implementación física, la decisión arquitectónica pasa a depender no de un supuesto ahorro inmediato en la nube, sino de la madurez del código de la aplicación y del rigor en el control del presupuesto mensual. Los costos de inversión inicial para el entorno local (equipo y licencias) fueron de R$ 24.399,00 y de implementación (física y lógica) de R$ 9.200,00, con un costo operativo recurrente mensual de R$ 1.300,00. Para la nube, no hubo inversión inicial, pero el costo operativo recurrente mensual fue de R$ 2.216,00.

Estudio de Escenarios, Escalabilidad y Proyección a Largo Plazo

Para profundizar la validación del modelo financiero y probar la resiliencia de ambas arquitecturas, se diseñó un estudio de escenarios extendiendo el ciclo de vida de la infraestructura a 60 meses (cinco años), plazo frecuentemente adoptado por el mercado corporativo para la renovación total de parques de servidores. Al recalcular la dilución de la inversión inicial local (R$ 33.599,00) por este nuevo plazo y sumar el costo operativo recurrente (R$ 1.300,00), el Costo Mensual Equivalente del entorno físico cae drásticamente a R$ 1.859,98. En contrapartida, el modelo de suscripción de servicio en la nube mantiene su piso estático de R$ 2.216,00, asumiendo un escenario optimista de ausencia de inflación o de reajustes de tabla por el proveedor. En este horizonte extendido, el entorno local se consolida como la opción financieramente más eficiente, comprobando que la longevidad operativa del activo físico recompensa de forma expresiva el capital inmovilizado.

Sin embargo, el factor de mayor criticidad para el negocio reside en la simulación de un escenario de estrés, como un aumento abrupto del 20% en el tráfico de datos. En una infraestructura local, el costo es fijo; someter al servidor a una carga mayor resultará principalmente en una degradación marginal del tiempo de respuesta interno, sin ninguna alteración en la factura mensual cobrada a la empresa. En la nube, el comportamiento es diametralmente opuesto y financieramente agresivo. Järvinen (2025) concluye que, en arquitecturas remotas no optimizadas, el costo en la nube escala de forma punitiva. Al enfrentar un aumento de carga, la plataforma configurada para escalabilidad automática intentará compensar la ineficiencia del software aprovisionando niveles máximos de computación (“scale-up”).

Una orden de magnitud para los impactos de esta escalabilidad reactiva es reportada por Cho’ponov (2026), quien estima un aumento de hasta el 132% en el TCO mensual cuando los sistemas mantienen fuertes acoplamientos y alta frecuencia de peticiones por la red. Adoptado a título ilustrativo, el costo de R$ 2.216,00 de la nube quedaría cercano a R$ 5.000,00 mensuales si la aplicación forzara la base de datos a escalar hasta el techo de procesamiento a fin de mitigar el impacto de la latencia. El valor constituye un escenario de sensibilidad, y no una proyección validada empíricamente. Por último, es imperativo añadir a la proyección los costos de salida de datos (“data egress”). Pillai (2024) advierte que muchas empresas son atraídas por el bajo costo de entrada en la nube, pero se vuelven rehénes de tarifas elevadas al transaccionar grandes volúmenes de datos de vuelta a las redes locales. En el modelo local evaluado, el tráfico interno es gratuito e ilimitado. Esta soberanía sobre el tránsito de la información, aliada al blindaje contra la escalabilidad reactiva, confiere a la infraestructura local una ventaja estratégica incomparable, protegiendo el flujo de caja corporativo y evidenciando que el éxito de la nube exige una optimización profunda y obligatoria del código del sistema.

Comparación con Alternativas de Mercado y Punto de Equilibrio

La paridad identificada se refiere a dos modelos específicos: la adquisición propia y la suscripción de banco como servicio en capa de entrada. El mercado, sin embargo, ofrece modalidades intermedias cuya omisión empobrecería el análisis. Entre las alternativas de mercado para alojamiento de bases de datos relacionales, destacan el servicio gestionado bajo demanda, el servicio gestionado con reserva, la máquina virtual autogestionada, el servidor dedicado o colocación, y la infraestructura local propia. La diferenciación más relevante reside en el licenciamiento y en el tráfico. En las ofertas gestionadas, la licencia del motor está integrada en la tarifa, lo que favorece a organizaciones sin licencias previas, mientras que empresas con licencias amortizadas tienden a pagar dos veces por el mismo derecho de uso. La capacidad reservada acerca la nube al modelo de adquisición, suprimiendo sin embargo la elasticidad que constituye su principal atractivo.

Aplicando los valores de esta investigación, se obtiene el punto de equilibrio entre los dos modelos. Con una inversión inicial de R$ 33.599,00 y un costo recurrente de R$ 1.300,00 mensuales en el entorno local, frente a R$ 2.216,00 en la suscripción, el ahorro operativo mensual es de R$ 916,00, lo que sitúa el punto de equilibrio en aproximadamente 36,7 meses. Esto explica la paridad observada en el ciclo de treinta y seis meses: el horizonte adoptado coincide casi exactamente con el momento en que la inversión se amortiza, razón por la cual los costos mensuales equivalentes convergen. El punto de equilibrio ofrece un criterio objetivo: horizontes inferiores a treinta y seis meses, o con incertidumbre sobre la continuidad, favorecen la suscripción, que prescinde de la inmovilización de capital; horizontes superiores favorecen la adquisición.

Dos evidencias externas corroboran la lectura. Flexera (2025) determinó que el 27% del gasto declarado en infraestructura y plataforma como servicio corresponde a recursos no utilizados o mal dimensionados, una proporción compatible con la ociosidad aquí medida; el desperdicio no se deriva de un sobreprecio del proveedor, sino de una capacidad que la arquitectura no puede consumir. De manera convergente, la repatriación llevada a cabo por la empresa 37signals, con un ahorro proyectado superior a diez millones de dólares en cinco años (Hansson, 2024), ilustra a escala industrial el mismo mecanismo. Para el mercado corporativo y para la gestión de tecnología, estos hallazgos generan implicaciones prácticas inmediatas. Queda claro que la estrategia de migración basada en la simple transferencia directa de sistemas legados es técnicamente fallida y propensa a riesgos. Los sistemas monolíticos, diseñados asumiendo la latencia casi nula de una red local, no pueden ser transpuestos a la nube sin una profunda refactorización de su lógica de comunicación.

El éxito de la computación en la nube exige el fomento de una cultura de excelencia en ingeniería y operaciones financieras, requiriendo la modernización de los sistemas hacia arquitecturas orientadas a eventos y procesamiento por lotes. En los escenarios donde esta refactorización sea inviable o donde la soberanía informacional y la previsibilidad presupuestaria sean prioridades, la infraestructura local se mantiene como una elección técnica soberana y recomendada. En síntesis, los resultados demuestran que la degradación del rendimiento en la nube no se deriva de la capacidad computacional, sino de la interacción entre la latencia de ruta y el patrón de comunicación unitario de la aplicación, impactando directamente el Costo Total de Propiedad y la viabilidad a largo plazo, consolidando la infraestructura local como la estrategia más viable para sistemas heredados sin optimización.

4. Conclusión

El presente estudio analizó el rendimiento y el Costo Total de Propiedad de operaciones de bases de datos en infraestructuras de nube y locales. Se observó que la degradación del rendimiento en la nube no se debió a la capacidad computacional, sino a la interacción entre la latencia de ruta y el patrón de comunicación unitario de la aplicación, lo que obligó al motor de base de datos a operar con casi el 98% de inactividad de la CPU. Por el contrario, el entorno local obtuvo un rendimiento superior, amparado por la comunicación de red casi instantánea, revelando el verdadero costo computacional de las operaciones. En el aspecto financiero, se observó un empate empírico en el Costo Total de Propiedad en un horizonte de treinta y seis meses, pero el entorno local se consolidó como la opción más ventajosa en un ciclo de sesenta meses y en escenarios de estrés, debido a la previsibilidad presupuestaria y a la soberanía de los datos. La principal contribución del trabajo reside en la elaboración de una matriz de decisión que auxilia a los gestores a dirigir sus estrategias tecnológicas, evidenciando que la adopción de la nube exige una optimización profunda de la arquitectura del sistema para minimizar la dependencia de la comunicación constante con el servidor remoto.

A pesar de la robustez de las pruebas, este trabajo reconoce sus limitaciones metodológicas, ya que el alcance se centró en el paradigma de bases de datos relacionales estándar del mercado, bajo configuraciones de hardware de entrada, y utilizó paquetes de datos de tamaño estático. Se sugiere que investigaciones futuras repliquen este modelo utilizando tecnologías no relacionales, investigando si la consistencia eventual mitiga los efectos de la latencia. También se recomienda cuantificar el costo de la mano de obra necesaria para la modernización de los sistemas heredados, integrando este valor al cálculo global de proyectos de migración. Sin esta modernización, la infraestructura local se consolidó como la estrategia más viable para sistemas heredados, garantizando alto rendimiento, previsibilidad presupuestaria y soberanía de los datos.

Referencias Bibliográficas

DAPPERLIB. Dapper: a simple object mapper for .Net. [S. I.]: Stack Exchange, 2024. Disponível em: https://github.com/DapperLib/Dapper. Acesso em: 2

Holmnäs, F. 2024. Migration of Customer Data from an On-premise Database to Cloud Infrastructure. Dissertação (Mestrado em Engenharia de Computação) – Faculty of Science and Engineering, Åbo Akademi University, Finlândia. Disponível em: https://www.doria.fi/bitstream/handle/10024/190527/holmnas_fredrik.pdf?sequence=2&isAllowed=y. Acesso em: 25 jan. 2026.

Husain, M. E.; Hussain, I.; Tanweer, S.; Khan, I. R. 2024. Transitioning from Data Centers to Cloud: An In-depth Analysis of Microsoft SQL Server’s Role in DBaaS and On-Premise Solutions. ICIMMI 2023: Proceedings of the 5th International Conference on Information Management & Machine Intelligence. Disponível em: https://dl.acm.org/doi/10.1145/3647444.3652491. Acesso em: 31 mar. 2026.

Kumar, S. 2024. Cloud vs. on-premises: choosing the right data architecture for scalable, secure solutions. International Journal for Multidisciplinary Research 6(6): 1-9. Disponível em: https://www.researchgate.net/publication/394789475_Cloud_vs_On_Premises_Choosing_the_Right_Data_Architecture_for_Scalable_Secure_Solutions. Acesso em: 25 jan. 2026.

Noor, I.; Tariq, S.B.; Shabbir, A.; Aksa, M. 2024. Into the future with cloud: a comparison with on-premises data warehouse. IEOM Society International, Dubai. Disponível em: https://ieomsociety.org/proceedings/2024dubai/541.pdf. Acesso em: 25 jan. 2026.

Pillai, P. 2024. Cloud vs. On-Premise Data Warehousing: A Strategic Analysis for Financial Institutions. Journal of Computer Science and Technology Studies 6(1): 1-12. Disponível em: https://www.al-kindipublisher.com/index.php/jcsts/article/view/9396. Acesso em: 31 mar. 2026.

Xu, D.; Li, T.; Sun, Z.; Chen, Z.; Zhou, W.; Zhang, Y.; Lu, W.; Du, X. 2025. Performant Synchronization in Geo-Distributed Databases. arXiv. Disponível em: <https://arxiv.org/abs/2511.22444>. Acesso em: 17 ago. 2026.

Zhang, G.; Tang, X.; Chang, Q.; Zhang, H.; Hwang, K.; Li, Y.; Huang, R.; Wang, T.; Zhang, W.; Zhang, M.; Chen, Q.; Hou, X.; Wang, Q. 2025. A Low Latency Cache for Cloud RDBMs. VLDB 2025 Workshop: DATAI. Disponível em: <https://www.vldb.org/2025/Workshops/VLDB-Workshops-2025/DATAI/DATAI25_3.pdf>. Acesso em: 17 ago. 2026.

Artículo originario del Trabajo de Conclusión de Curso de la Especialización en Ingeniería de Software del MBA USP/Esalq

Para saber más sobre el curso, haga clic aquí y acceda a la plataforma MBX Academy