Sistemas de archivos y bases de datos: el círculo que se cierra

Durante años migramos desde aplicaciones centradas en archivos, con formatos rígidos, duplicación y cierres exclusivos, hacia DBMS capaces de ofrecer ACID, transacciones, índices, integridad referencial, control de concurrencia, auditoría, backup/restore, replicación y disaster recovery. Ese salto ordenó el dato, mejoró la búsqueda y permitió operar con consistencia y previsibilidad en escenarios críticos.

Con big data y cloud, el péndulo no volvió atrás, pero sí completó un círculo. El almacenamiento en archivos/objetos recuperó protagonismo por costo, escala y apertura: HDFS y, sobre todo, object storage como S3, GCS o ADLS; formatos columnares como Parquet y ORC; y formatos de tabla abiertos (Iceberg, Delta Lake, Hudi) que aportan time travel, transacciones, compaction y gobernanza. La separación storage/compute habilita motores elásticos y serverless (Spark, Flink, Trino, DuckDB, Athena) con schema-on-read, multi-tenant y data sharing sin copias, apoyando pipelines analíticos y de ML con latencias y costos controlados.

Hoy conviven mundos. Para OLTP de baja latencia, invariantes fuertes y write-heavy, un DBMS transaccional sigue siendo la herramienta correcta. Para analítica, entrenamiento de modelos, historización de streams y archivado, los objetos y formatos columnares dominan. Entre ambos, patrones como CDC hacia logs append-only, lakehouse, external tables, materialized views y consultas federadas integran flujos sin fricción. La capa de metadatos y gobierno es clave: catálogos, lineage, cifrado con KMS, RBAC/ABAC, WORM con Object Lock, versionado, snapshots y replicación cruzada elevan seguridad y resiliencia end-to-end.

No se trata de elegir bando, sino de hacer explícitos los principios: transaccionalidad donde aporta valor, formatos abiertos donde escalan los costos y la interoperabilidad. Diseñar metadatos como primera clase, definir SLA/SLO por dataset, automatizar pipelines idempotentes con validaciones de esquemas y contract testing, y tratar el costo como requisito (compresión, particionamiento, z-order, lifecycle policies) son prácticas que separan éxito de deuda técnica. En performance, predicate pushdown, column pruning y caching; en resiliencia, chaos drills y playbooks de recuperación cierran el loop operativo.

¿Qué criterios concretos usás hoy para decidir si un dataset vive en una tabla transaccional o en un bucket de objetos, y cómo te fue con esa elección?