Someone suggests "put everything on S3" to cut cost. Except your PostgreSQL already runs on NVMe block — and a DBA reminds you that databases do not live in buckets.
Block storage (volume on a VPS, cloud disk, SAN) exposes a /dev/sdb device formatted ext4 or XFS. The database engine does random reads/writes, fsync, locks. Object storage exposes keys; each PUT replaces the whole object. Confusing the two for data changing every second is among the costliest architecture mistakes.
Block vs object: access semantics
| Need | Block disk | Object storage |
|---|---|---|
| MySQL / PostgreSQL / local MongoDB | Yes | No |
| Redis AOF/RDB persistence | Yes | No |
| Immutable photo upload | Possible but heavy | Ideal |
| Archived append-only logs | Block then rotate → object | Ideal (lifecycle) |
| Frequent partial updates | Yes (offset write) | No (full rewrite) |
| Crash-consistent snapshots | Yes (with care) | Per-object versioning |
Putting a database on S3 "because it scales" ignores that database scale comes from replication, not HTTP PUTs.
Frequently changing data: stay on block
Relational engines. Data directory, WAL, binlog: p99 latency and provisioned IOPS define load capacity. Cloud "database optimized" or NVMe volumes exist for this.
Persistent caches. Redis AOF, file sessions: small frequent writes — poor object fit.
Legacy POSIX apps. ERP writing hundreds of temp files in /tmp/app: block or local SSD.
Stateful containers. Named Docker volume for Elasticsearch or Prometheus TSDB — attached block, regular snapshots.
Block good practices: snapshot before major upgrade; monitor IOPS and free space with alert at 80%; separate data and OS on two volumes for targeted restore.
Rarely changing or write-once data: object wins
User media. Single write, many reads via CDN.
Backups and dumps. Compressed pg_dump to bucket with 30-day retention — classic and cheap.
Cold logs. 48h local block rotation, aggregate to cold-tier bucket.
CI artifacts. Versioned binaries, immutable by hash.
Scaleway, OVHcloud, and hyperscalers bill block and object separately: compare egress when restoring a database from S3 to a new volume.
The badly executed hybrid trap
Healthy pattern: database on NVMe, files on object, metadata in SQL.
Toxic pattern: database on block and critical app files only on block with no object backup — volume loss = total loss. Inverse toxic pattern: SQLite on NFS mounted from an object gateway — latency and corruption.
The peak: S3 billing is not architecture fit
Decide and move forward without blind spots
List each datastore with its write rhythm: operations per second, average size, mutable or immutable. Place databases and caches on block sized after real IOPS measurement under load. Export backups and media to object with lifecycle rules.
Test block volume restore and isolated object restore — not just backup creation. Browse block and object offers in our compare tool. For app files versus NAS, see Object storage or NAS.
Frequently asked questions
Can I host MySQL on object storage?
Not in standard production. MySQL needs a low-latency block filesystem. Object for dumps and archives.
When does S3 replace a block volume?
Write-once, read-many files via SDK/CDN. Frequent rewrites favour block.
Are block snapshots enough for backup?
Not alone. Combine snapshots, off-site object export, and restore tests.
How do I pick IOPS size?
Profile at peak: sustained IOPS, p99 latency. Avoid blind over- or under-provisioning.
Before migrating a database "to the cloud", ask: how many random writes per second? If you do not know, block is not sized yet — and S3 is not the answer.