---
id: 2bc35fc657eb35eb5dbcb7286c1033ba
author: gosunuts
title: 'Servidores de bases de datos y bases de datos embebidas: comparación de arquitectura y características de E/S'
description: Se comparan las bases de datos RDBMS basadas en procesos independientes y las bases de datos embebidas en proceso, como SQLite, RocksDB, BadgerDB y PebbleDB, desde la perspectiva de la latencia de E/S de los SSD NVMe, el aislamiento de datos en arquitecturas MSA y la estructura de despliegue.
language: es
date: 2025-08-21T12:11:23.268337247Z
path: /blog/posts/database-servers-and-embedded-databases-zd4cb799f
category: database
---

## Servidor de base de datos

Un servidor de base de datos se refiere a una base de datos que se ejecuta como un proceso de servidor independiente y procesa las solicitudes de las aplicaciones a través de la red. La mayoría de los RDBMS que nos resultan familiares, como MySQL, PostgreSQL y Oracle DB, corresponden a este modelo. El servidor de base de datos presenta las siguientes ventajas.

- **Gestión centralizada**: los datos se administran de forma integrada en un único lugar, lo que facilita la consistencia, la seguridad, la copia de seguridad y la recuperación.
- **Independencia de recursos**: al disponer de CPU, memoria y almacenamiento propios, garantiza un rendimiento estable independientemente del estado de la aplicación.
- **Alta concurrencia y escalabilidad**: está optimizado para el acceso simultáneo de numerosos usuarios y, mediante la agrupación en clústeres o la replicación, la escalabilidad horizontal resulta relativamente sencilla.

Gracias a estas características, el servidor de base de datos se ha consolidado como estándar de la infraestructura de software durante las últimas décadas. Sin embargo, debido a los avances tecnológicos y a los cambios del entorno, las desventajas del servidor de base de datos han comenzado a manifestarse en algunos entornos, y como alternativa vuelven a cobrar atención las bases de datos embebidas.

## Una nueva tendencia: la base de datos embebida

Una base de datos embebida es un motor de base de datos que se incluye en la aplicación en forma de biblioteca y se ejecuta dentro del mismo proceso, sin un proceso de servidor independiente. SQLite, LevelDB y RocksDB son ejemplos representativos de bases de datos embebidas. Las razones por las que estas bases de datos embebidas han surgido como una alternativa sólida en el entorno tecnológico actual son las siguientes.

- **La aparición de los SSD**

  En los sistemas centrados en HDD del pasado, el rendimiento de los accesos aleatorios era muy inferior al de la lectura y escritura secuenciales de datos. Por ello, minimizar la E/S de disco y maximizar el uso de la caché en memoria constituía el núcleo de la optimización del rendimiento. Los servidores de base de datos, en consonancia con ello, operaban cachés de gran tamaño y procesaban las operaciones de escritura por lotes, superando así las limitaciones físicas de los HDD.

  Sin embargo, la aparición de los SSD cambió por completo esta premisa. Los SSD ofrecen un rendimiento de E/S aleatoria varias miles de veces superior al de los HDD, y su latencia es notablemente menor. Como resultado, desapareció la percepción tradicional de que "la E/S de disco es el mayor cuello de botella", y empezó a destacar como nuevo cuello de botella la latencia que surge en el acceso remoto a un servidor de base de datos a través de la red.

- **MSA y la independencia de los datos**

  En el pasado, era habitual una estructura en la que una aplicación monolítica de gran tamaño dependía de una única base de datos centralizada. Aunque este enfoque es simple, a medida que crece la escala del servicio resulta difícil modificar el esquema de datos, y existe el problema de que, al compartir todos los servicios la misma base de datos, el acoplamiento se vuelve excesivamente fuerte.

  En la arquitectura de microservicios moderna, para resolver estos problemas se da gran importancia al principio "Database per Service". Cuando cada servicio posee y encapsula su propio almacén de datos dedicado, se garantiza la independencia entre servicios, y el aislamiento de fallos y la escalabilidad se vuelven más sencillos. En este proceso, la base de datos embebida se convierte en una opción ideal como almacén de datos a nivel de servicio. Es ligera y rápida, y como puede desplegarse junto con el código del servicio, encaja muy bien con los entornos MSA.

  Por ejemplo, en entornos Kubernetes se utiliza ampliamente el patrón sidecar, que coloca una base de datos embebida junto al contenedor de la aplicación para optimizar el procesamiento local de datos. Esto reduce el cuello de botella de la red y minimiza la latencia de acceso a los datos.

- **Simplificación del entorno operativo**

  Los servidores de base de datos requieren procedimientos operativos complejos como la instalación, los parches, las copias de seguridad, la recuperación ante fallos, la replicación y la supervisión del rendimiento, y para ello se necesitan DBA dedicados y personal operativo especializado. Especialmente en entornos de gran escala, esta carga de gestión es muy considerable.

  La base de datos embebida alivia significativamente estos problemas. Cuando la base de datos se integra dentro de la aplicación, la prueba unitaria, la compilación, el control de versiones y el despliegue se realizan conjuntamente, por lo que no es necesaria una operación de servidor independiente. Además, cuando la aplicación escala horizontalmente, la base de datos embebida también se expande junto con ella, y es posible una gestión automatizada mediante la cultura DevOps y los pipelines de CI/CD. En particular, en startups, servicios de pequeña escala y entornos de desarrollo de prototipos, la base de datos embebida reduce drásticamente la complejidad operativa y aumenta de forma notable la velocidad de desarrollo y despliegue.

- **Lenguajes de sistemas de alto rendimiento y desarrollo del ecosistema**

  En el pasado, era habitual que la base de datos y la aplicación se escribieran en lenguajes diferentes. Por ejemplo, los motores de bases de datos de alto rendimiento se escribían principalmente en C y C++, mientras que las aplicaciones se desarrollaban con lenguajes como Java, Python o PHP. Este enfoque era eficaz para la optimización del rendimiento, pero presentaba limitaciones como los problemas de seguridad de memoria, la complejidad del procesamiento concurrente, la latencia y las dificultades en la integración y el despliegue de bibliotecas.

  Sin embargo, con el auge reciente de lenguajes de programación de sistemas modernos como Go y Rust, estas limitaciones se han aliviado considerablemente. En particular, Go es adecuado tanto para aplicaciones de alto rendimiento como para la escritura de programas de bajo nivel como los motores de bases de datos, lo que permite tratar la base de datos y la aplicación dentro de un mismo ecosistema lingüístico.

  De hecho, en Golang se utilizan activamente bases de datos embebidas de alto rendimiento como [BadgerDB](https://github.com/hypermodeinc/badger) y [PebbleDB](https://github.com/cockroachdb/pebble). Esto indica que la base de datos embebida, más allá de ser una alternativa ligera al servidor de base de datos, se ha consolidado como una opción importante con competitividad propia.

## Conclusión

En condiciones que requieren la gestión centralizada de datos a gran escala, transacciones complejas y alta concurrencia, el servidor de base de datos sigue siendo la solución más potente. No obstante, en componentes individuales de entornos MSA, dispositivos IoT en el borde, prototipado rápido y proyectos en los que la eficiencia operativa es importante, la base de datos embebida puede constituir una elección más eficiente y razonable. En última instancia, lo importante es elegir la herramienta óptima que mejor se ajuste a la situación y a los requisitos dados, y el desarrollo de las bases de datos embebidas nos ofrece opciones más amplias y diversas.
