Object storage
Object storage vs block storage: API objects or virtual disks?
Object storage and block storage both hold bytes, but applications interact with those bytes differently. Treating one as a cheaper substitute for the other can create performance and correctness problems that no amount of extra capacity fixes.
Block storage presents addressable blocks
A virtual disk lets an operating system place a filesystem, swap area or database storage engine on top. Software can overwrite small regions and depend on filesystem semantics, locking and local caching.
This is the normal shape for a VM root disk, relational database files and applications that expect a mounted volume. The storage system sits underneath the filesystem that the operating system manages.
Object storage presents named objects over HTTP
S3-style applications send requests for complete objects or multipart pieces. They address a bucket and key, not disk sectors, and usually replace an object as a whole. Arbitrary in-place byte-range writes are not the normal object-storage model.
This model scales well for independent blobs such as images, archives, backups and generated artifacts because the application does not need a shared POSIX filesystem.
Latency expectations are different
A database can issue many tiny synchronous writes and expect low-latency block acknowledgement. An object workload may tolerate higher per-request latency because it transfers larger independent objects and parallelizes them.
Benchmark with the actual request size and concurrency. A throughput result from large multipart objects says very little about how a database would behave on the same network path.
Snapshots and versioning solve different problems
Block platforms often snapshot a volume at a point in time. Object platforms can retain versions of individual keys or apply retention rules to object generations.
Neither mechanism automatically creates application consistency. Databases and stateful services still need a backup process that understands how to capture a recoverable state before storage-level copies become useful.
Use both when the application needs both
A common design keeps the database and active application filesystem on block storage while moving uploads, exports and backup artifacts to object storage. That separates hot mutable state from large independent blobs.
Choose each storage layer for its access pattern. A simpler architecture diagram is not a reason to force every workload into one medium.