53 puntos por xguru 2024-12-09 | 14 comentarios | Compartir por WhatsApp
  • Se presentan 7 BD que vale la pena seguir de cerca para resolver distintos problemas
  • No es una lista de las “mejores BD”, sino de herramientas que ofrecen perspectivas nuevas y útiles
  • Ojalá en 2025 puedas invertir una semana en cada una de estas BD (7 DBs in 7 Weeks)

1. PostgreSQL: la base de datos por defecto

  • PostgreSQL es una tecnología estable que se usa por defecto
    • La frase “Just use Postgres” es un meme ampliamente conocido y una expresión que simboliza confianza
    • Cumple con ACID y ofrece funciones sólidas, incluida replicación física y lógica
    • Es una base de datos estable con amplio soporte entre los principales vendors
  • El mayor atractivo de PostgreSQL: su extensibilidad
    • A través de extensiones (Extensions), se pueden agregar capacidades originales
    • Ejemplos de extensiones importantes:
      • AGE: soporte para estructuras de datos de grafos y el lenguaje de consultas Cypher
      • TimescaleDB: soporte para trabajar con datos de series temporales
      • Hydra Columnar: ofrece un motor de almacenamiento por columnas
    • Las extensiones son un elemento clave que diferencia a PostgreSQL de otras bases de datos
  • La utilidad y extensibilidad de PostgreSQL
    • Tiene un ecosistema muy amplio, y su configuración por defecto es razonable y amigable para el usuario
    • Incluso servicios que no son PostgreSQL ofrecen compatibilidad de clientes mediante el protocolo wire de Postgres
    • Es lo suficientemente ligero como para poder instalarse incluso en entornos WebAssembly (Wasm)
  • Se recomienda aprender PostgreSQL
    • Vale la pena invertir tiempo para entender las posibilidades y límites de PostgreSQL
    • Ejemplo: comprender la complejidad de MVCC (Multi-Version Concurrency Control)
    • Se recomienda desarrollar una aplicación CRUD simple y también escribir extensiones para PostgreSQL

2. SQLite: la base de datos local-first

  • SQLite es una base de datos “local-first” que puede ejecutarse de forma independiente
    • Sale del modelo cliente-servidor y corre en el mismo entorno que la aplicación
    • Ejemplo: WhatsApp y Signal usan SQLite dentro del dispositivo para almacenar los datos de chat
  • Casos de uso más avanzados de SQLite
    • Permite usos creativos más allá de una base de datos ACID básica
    • Nuevas herramientas y extensiones:
      • Litestream: ofrece backups en streaming para SQLite
      • LiteFS: soporta acceso distribuido para implementar topologías más flexibles
      • CR-SQLite: usando CRDT (Conflict-free Replicated Data Types), elimina la necesidad de resolver conflictos al fusionar conjuntos de cambios
  • El renovado interés en SQLite
    • Está recibiendo atención nuevamente gracias a Ruby on Rails 8.0
    • 37signals: desarrolla módulos de Rails basados en SQLite (como Solid Queue)
      • Soporte de Rails para administrar múltiples bases de datos SQLite (database.yml)
    • Bluesky: usa una base de datos SQLite separada por usuario como Personal Data Server
  • Se recomienda aprender a usar SQLite
    • Experimentar con arquitecturas centradas en lo local usando SQLite
    • Probar si el modelo cliente-servidor tradicional basado en PostgreSQL puede reemplazarse con SQLite

3. DuckDB: la base de datos que puede consultar todo

  • DuckDB es una base de datos embebida especializada en OLAP
    • Al igual que SQLite, funciona junto con la aplicación, pero se enfoca en tareas OLAP en lugar de OLTP
    • Es un sistema diseñado alrededor del análisis y las consultas de datos
  • La característica “Query-Anything” de DuckDB
    • Permite consultar directamente con SQL diversas fuentes de datos:
      • Formatos de archivo comunes como CSV, TSV y JSON
      • Soporte para formatos más avanzados como Parquet
    • Esta capacidad brinda mucha flexibilidad; por ejemplo, para analizar streams de datos de Bluesky
  • Extensibilidad y ecosistema
    • DuckDB también tiene extensiones, aunque no tan abundantes como Postgres (es un proyecto relativamente joven)
    • Hay muchas extensiones aportadas por la comunidad, y gsheets (integración con Google Sheets) destaca especialmente
  • Se recomienda aprender a usar DuckDB
    • Experimentar con análisis y procesamiento de datos mediante notebooks de Python o Evidence
    • Combinarlo con SQLite: delegar en DuckDB las consultas analíticas sobre una base de datos SQLite para mejorar el rendimiento

4. ClickHouse: base de datos columnar

  • ClickHouse es una base de datos especializada en cargas de trabajo OLAP
    • La combinación ideal es PostgreSQL para OLTP y ClickHouse para OLAP
    • Maneja cargas analíticas a gran escala y soporta altas velocidades de inserción de datos mediante escalado horizontal y sharding
  • Características principales de ClickHouse
    • Soporte para almacenamiento jerárquico:
      • Permite separar y almacenar “hot data” y “cold data”
      • Ejemplo: la documentación de GitLab trata este caso de uso en detalle
    • Procesamiento de datasets masivos y análisis en tiempo real:
      • Adecuado para datasets de un tamaño que sería difícil de manejar con DuckDB
      • Ofrece un rendimiento potente en situaciones que requieren análisis en tiempo real
  • Facilidad operativa
    • La documentación relacionada con despliegue, escalado y backups está bien organizada y es detallada
    • Ejemplo: incluso ofrece documentación sobre cómo configurar correctamente la CPU
  • Se recomienda aprender ClickHouse
    • Experimentar con grandes datasets analíticos o migrar a ClickHouse análisis hechos en DuckDB
    • Usar chDB, la versión embebida de ClickHouse, para compararlo más directamente con SQLite

5. FoundationDB: la base de datos en capas

  • FoundationDB es un sistema singular que funciona como “base de las bases de datos”
    • Fue diseñado como un almacén clave-valor, pero más que una base de datos simple, actúa como “fundación” para construir bases de datos
    • Lo utilizan grandes empresas como Apple, Snowflake y Tigris Data
  • Características principales y limitaciones
    • Restricciones:
      • Los datos de una transacción no pueden exceder 10MB
      • Una transacción no puede durar más de 5 segundos desde la primera lectura
    • Gracias a estas restricciones, puede ofrecer transacciones ACID completas incluso en entornos de gran escala
      • Ejemplo: casos de operación de clústeres de más de 100TiB
  • Diseño y pruebas de FoundationDB
    • Está diseñado con optimización para cargas de trabajo específicas
    • Pruebas por simulación para demostrar estabilidad y escalabilidad:
      • Antithesis y otras bases de datos también usan la misma metodología de pruebas
      • Material relacionado: documentos de Tyler Neely y Phil Eaton
  • FoundationDB como base de datos “en capas”
    • El acoplamiento entre el motor de almacenamiento y el modelo de datos es laxo:
      • Se puede remapear el motor de almacenamiento en distintas capas
      • Ejemplo: Record Layer, Document Layer (ofrecidos por la organización de FoundationDB)
    • Vale la pena revisar ejemplos de diseño de capas escritos por Tigris Data
  • Se recomienda aprender FoundationDB
    • Seguir tutoriales y explorar su potencial para reemplazar sistemas como RocksDB
    • Leer sobre métodos de diseño (Design Recipes) y artículos relacionados
    • Entender sus límites de uso y los problemas que puede resolver mediante los documentos Anti-Features y Features

6. TigerBeetle: una base de datos obsesionada con la exactitud

  • TigerBeetle es una base de datos de propósito único especializada en transacciones financieras
    • A diferencia de una base de datos de propósito general, se enfoca en un objetivo específico, en especial las operaciones financieras
    • Es open source y fue diseñada con el objetivo de ofrecer un nivel muy alto de confiabilidad y exactitud
  • Filosofía de diseño para una exactitud rigurosa
    • Implementa las Power of Ten Rules de la NASA y Protocol-Aware Recovery
    • Usa strict serialisability y Direct I/O para evitar problemas relacionados con la page cache del kernel
    • Esa rigurosidad también se ve en el documento de seguridad (Safety doc) y en su estilo de programación único, “Tiger Style”
  • Un enfoque innovador implementado en Zig
    • Zig es un lenguaje de programación de sistemas relativamente nuevo, pero encaja de forma ideal con los objetivos de TigerBeetle
    • Aprovecha las ventajas de Zig para maximizar simplicidad y rendimiento
  • Propuestas para aprender y usar TigerBeetle
    • Experimentar con el modelado de cuentas financieras en un entorno de despliegue local:
      • Instalarlo y usarlo siguiendo el Quick Start
    • Consultar la documentación de arquitectura del sistema (System Architecture docs) para explorar cómo combinarlo con bases de datos de propósito general
    • Ejemplo: integrarlo con PostgreSQL o FoundationDB para ampliar sus casos de uso

7. CockroachDB: la base de datos global

  • CockroachDB es una base de datos distribuida global
    • Es compatible con el protocolo wire de PostgreSQL y soporta escalado horizontal y consistencia fuerte
    • Su diseño, inspirado en Google Spanner, permite escalar la base de datos a través de múltiples regiones
  • Principales características técnicas de CockroachDB
    • Tecnología de sincronización de tiempo:
      • Google Spanner usa relojes atómicos y GPS, pero CockroachDB fue diseñado para funcionar también sobre hardware común
      • Compensación de latencia de sincronización basada en NTP, comparación del clock drift entre nodos y expulsión de miembros cuando se supera el máximo offset
    • Configuración multi-región:
      • La función Table Localities permite optimizar según los trade-offs de lectura/escritura
      • Los datos se distribuyen de acuerdo con la ubicación geográfica de los usuarios para mejorar rendimiento y latencia
  • Sugerencias para aprender y usar CockroachDB
    • Reimplementar el ejemplo MovR:
      • Implementar MovR (ejemplo de aplicación distribuida) usando el lenguaje y framework que prefieras
    • Experimentar con el diseño de aplicaciones globales aprovechando las estrategias multi-región y de escalado de CockroachDB
  • Por qué elegir CockroachDB
    • A diferencia de otras bases de datos distribuidas como DynamoDB, puede ejecutarse gratis en entorno local
    • Ofrece la combinación diferenciadora de consistencia fuerte y soporte para distribución global

Cierre

  • Las bases de datos presentadas fueron diseñadas para resolver problemas y necesidades distintas
  • ¡En 2025, estudia estas bases de datos y explora formas más interesantes y creativas de resolver problemas!

14 comentarios

 
wfedev 2025-11-28

¡Consulta cualquier cosa! 😆🐤

 
budaestew 2024-12-16

Me sorprendió lo sobresaliente que es el rendimiento de análisis de DuckDB, más de lo que esperaba.

 
halfenif 2024-12-09

Llevo varios meses usando sqlite. Por fecha. Estoy realizando tareas que procesan alrededor de 2 millones de registros y unos 5 GB de datos.

La velocidad de procesamiento me satisface, pero... después de procesar esto y volver a convertirlo en Excel para entregarlo a las partes interesadas, está tomando demasiado tiempo.

Creo que tendré que investigar un poco más la forma de usar OpenPyXl.

 
kimjj81 2024-12-18

No sé qué magia tendrá, pero dicen que usan una combinación de duckDB + sqlite.

 
channprj 2024-12-09

Curiosamente, no se mencionó MongoDB.

 
felizgeek 2024-12-09

Si te preocupa el nivel de dificultad de aprendizaje para desarrolladores en tu entorno, te recomiendo SQLite. Al estar basado en archivos, es fácil.

 
savvykang 2024-12-09

Si está claro que no se requieren accesos remotos, es una solución realmente satisfactoria. Elimina los puntos de gestión de la base de datos y además facilita la edición de datos, así como el respaldo y la recuperación.

 
aer0700 2024-12-09

Cuando dices que vas a usar SQLite, es fácil que te caigan críticas, pero antes de decir que usaste SQLite, nadie se da cuenta tampoco... SQLite es mejor de lo que parece.

 
jpumpkin94 2024-12-09

Llevo usando solo MySQL desde hace décadas (??),
pero me gustaría saber qué tal es PostgreSQL. Espero muchos comentarios de quienes lo usan en producción en el trabajo real.

 
zuppiy 2024-12-09

"Los elefantes son superiores a las focas"
Esto es cierto en la mayoría de las situaciones

 
roxie 2024-12-11

jajaja

 
kibae 2024-12-09

En 2001 me pasé de mysql, lleno de bugs en ese entonces (v3.x), a pgsql.
Hay muchas cosas en las que me parece superior, pero... en la práctica creo que la existencia de los índices parciales es la función más poderosa.

 
chanhee 2024-12-09

Por trabajo en la empresa solo usaba Oracle y SQL Server, pero cuando intenté usar MySQL, de verdad hubo demasiadas cosas que me hicieron pensar: "¿por qué esto no funciona?" La verdad ya no lo recuerdo con exactitud.
Al final terminé pasándome a Postgres.

 
bbulbum 2024-12-09

Al venir de usar Postgres a un lugar donde usan MySQL, hay bastantes cosas en las que sientes: ¿por qué esto no se puede hacer? ¿por qué esto no da ese rendimiento?
No recuerdo bien exactamente qué era (puede que fuera algo menor o puede que no).