Storage, backup and archive are different decisions

Storage conversations get messy when different layers are compared as if they were equivalent products. S3, a data lake, Parquet and Snowflake can all appear in the same architecture, but they do not do the same job.

The practical question is not which one is best. The practical question is which layer is being decided.

Start With The Layer

A useful data system usually has several layers:

physical storage
storage interface
data format
table or database engine
query and processing
catalog, governance and security
backup, archive and recovery

Object storage such as S3 or MinIO can hold files, raw datasets, backup objects, media and lakehouse data. It is a storage foundation. It is not, by itself, a governed analytics platform.

Parquet is a file format. It describes how columnar data is encoded. It does not decide access control, retention, lineage or recovery.

Apache Iceberg, Delta Lake and Hudi add table metadata and transaction behavior on top of object storage. They help turn files into governed tables.

Snowflake, BigQuery, Redshift and similar systems provide managed analytical databases or warehouses. They include query, compute, metadata and operational behavior that object storage alone does not provide.

Storage Interfaces Are Not The Same

Block storage presents volumes to virtual machines, databases and low-latency systems. It is often close to compute and expects a filesystem or database above it.

File storage presents shared directories. It fits collaborative file access, legacy applications, research folders and POSIX-like workflows.

Object storage presents buckets and objects. It fits large-scale durable storage, backups, application files, data lakes and archives, but applications must be designed for that access model.

Distributed file systems such as CephFS, Lustre, BeeGFS or HDFS spread data across a cluster. They can be powerful, but the operational model is different from a simple managed cloud bucket.

Databases Are Storage With Behavior

A database is not only a place where bytes live. It also defines behavior: transactions, indexes, query language, consistency, concurrency, replication, recovery and access patterns.

PostgreSQL, MySQL and MariaDB are common choices for transactional business data. Redis is useful for caching and sessions. OpenSearch fits search and log exploration. Vector databases help with semantic retrieval. Time-series systems fit metrics and sensor streams.

The right database depends on access patterns and operating model. A data lake should not be used to replace a transactional database. A relational database should not be used as a cheap archive for everything.

Backup Is Not Archive

Backups are recovery copies. They exist so a system can be restored after loss, corruption, deletion or operational failure. A good backup design answers restore scope, restore time, restore point, test frequency and evidence.

Archives are long-term records. They exist for retention, research, compliance, history or low-access storage economics. A good archive design answers retention, format durability, metadata, access control, legal hold and eventual readability.

The same object store might hold backup objects and archive objects, but those are still different decisions. They need different policies and different proof.

Data Lakes Need Governance

A data lake is not simply a bucket full of files. A useful lake needs conventions for layout, formats, metadata, access, ownership, quality, lineage and lifecycle.

A lakehouse adds table semantics to lake storage. That can be a good fit when teams need open storage, analytical tables and multiple query engines. But the implementation still needs catalog, permissions, monitoring and recovery planning.

This is why the layers matter. A lakehouse might combine:

object storage
Parquet files
Iceberg tables
catalog metadata
Trino or Spark queries
Airflow workflows
Ranger or IAM controls
backup and retention policy

None of those layers replaces all the others.

A Practical Shortlist

For many organizations, a sensible starting map looks like this:

Need	Typical choice
Transactional business data	PostgreSQL or another relational database
Files, raw data and backups	S3-compatible object storage
Caching and sessions	Redis
Event streams	Kafka or compatible streaming log
Lakehouse tables	Iceberg or Delta
Analytics and reporting	Snowflake, BigQuery, ClickHouse or similar
Search and logs	OpenSearch or equivalent
Semantic retrieval	Vector database or PostgreSQL with vector extension

This shortlist is not a universal blueprint. It is a way to prevent confused comparisons.

What LibreInfra Reviews

LibreInfra looks at the full data path:

• where bytes are stored
• how applications read and write them
• which format and table contracts exist
• what query engines depend on them
• how metadata and ownership are managed
• how access is granted and audited
• how backup and restore are proven
• how archives remain readable over time

The outcome should be a storage and data architecture that can be operated, recovered and transferred without relying on one person’s memory.