Bases de datos y por qué su complejidad ya no es necesaria

Artículo original ↗ Discusión en Hacker News ↗

Una publicación de blog que argumenta que las bases de datos relacionales tradicionales son demasiado complejas y están fundamentalmente defectuosas ha provocado debate sobre cuándo sus restricciones son en realidad una fortaleza. Los comentaristas contraponen la simplicidad de “una gran base de datos SQL” para la mayoría de las startups y sistemas empresariales con las necesidades de arquitecturas dirigidas por eventos a escala de petabytes, donde los logs junto con vistas materializadas y herramientas como Rama, Kafka o Datomic pueden destacar. Muchos siguen siendo escépticos ante las afirmaciones de Rama de reemplazar las bases de datos —citando la complejidad operativa, el bloqueo al JVM y las lecciones aprendidas con event sourcing—, aunque reconocen que una mejor herramienta para la evolución de esquemas, el indexado y el procesamiento de datos a gran escala sigue siendo un problema sin resolver.

Una sola base de datos vs. varias bases de datos

  • Fuerte apoyo a la idea de “una gran base de datos” como superpoder: semántica más simple, sin transacciones distribuidas, depuración más fácil y, a menudo, escala suficiente para la mayoría de las empresas.
  • Contraargumentos:
    • Inevitablemente tienes al menos otro almacén de datos para la infraestructura (por ejemplo, etcd/ZooKeeper/metadatos de K8s).
    • A mayor escala o con necesidades de aislamiento más estrictas, dividir los datos (por servicio, inquilino o carga de trabajo) puede reducir el radio de explosión y permitir una evolución independiente.
    • Para muchas startups, un único RDBMS escalado verticalmente + un par de réplicas es suficiente; la fragmentación horizontal suele ser prematura.

Modelos relacionales, esquemas y complejidad

  • Algunos sostienen que cualquier dominio puede modelarse limpiamente con tuplas y relaciones; el límite real es el rendimiento, no la expresividad.
  • Otros subrayan que los esquemas restrictivos y la normalización son una característica: obligan a pensar, protegen la calidad de los datos y permiten consultas potentes.
  • Las quejas se centran más en la evolución del esquema, el riesgo de migraciones y las fugas del ORM que en el modelo relacional en sí.

Event sourcing + vistas materializadas

  • Muchos señalan que la mayoría de las bases de datos serias ya son “vistas materializadas sobre un log” (WAL/binlog).
  • Event sourcing recibe elogios en entornos de gran escala y con mucha ingeniería de datos, pero:
    • Muchos informan que añade código repetitivo, carga cognitiva, problemas de versionado, cuestiones de GDPR/anonymización y depuración dolorosa.
    • Varios dicen que se arrepintieron de adoptarlo fuera de casos de uso estrechos y bien justificados.
  • Otros reportan éxito cuando se usa de forma selectiva, a menudo con patrones Kafka/CDC/outbox y un RDBMS tradicional como almacén canónico.

Rama: arquitectura y reacciones

  • Rama se describe como: “depots” de solo anexado (logs de eventos) + flujos de datos distribuidos que construyen “PStates” arbitrarios (índices materializados) + topologías de consulta.
  • Se ejecuta en JVM con APIs para Java y Clojure, aspira a reemplazar la pila habitual “Postgres + cola + búsqueda + ETL”, y afirma consistencia fuerte, semántica similar a ACID y alta escalabilidad.
  • Comentarios entusiastas: gusta el modelo cohesivo, la telemetría integrada y la integración estrecha de ingestión, procesamiento y consulta.
  • Escepticismo:
    • El marketing pesado (“las bases de datos ya no son necesarias”, “escala de Twitter con 100x menos código”) parece exagerado; la demo es sintética, no una migración real en producción.
    • La API parece una DSL incrustada en Java; limitarse a JVM es una barrera; la curva de aprendizaje y el modelo mental no están claros.
    • Dudas de que simplifique aplicaciones empresariales típicas (por ejemplo, carritos de compra, contabilidad) frente a un buen RDBMS.

Estado mutable global, transacciones y evolución

  • Hay acuerdo en que el estado mutable global es inherentemente inevitable; los logs de eventos también mutan a medida que llegan nuevos eventos.
  • Las transacciones y restricciones de los RDBMS siguen siendo muy valoradas para cargas de trabajo tipo dinero; algunos ven el modelo de Rama como una simple reubicación, no una eliminación, de la complejidad.
  • Muchos desearían mejores herramientas para la evolución del esquema, migraciones blue/green y “schema as code”, independientemente de si usan bases de datos o logs de eventos.