Storage & Managed Data
Object, block and file storage as three different contracts, direct-upload architectures with signed authorization, and managed databases with an honest boundary — what the provider runs, and what remains entirely yours.
Three storage contracts, not three products: a blob you address by key and replace whole, a raw device your operating system formats, and a filesystem several machines mount at once. Choosing the wrong contract is the expensive mistake — the vendor is a footnote.
Q · Which storage contract does this data need — a whole-blob namespace, a raw device, or a filesystem several machines share?
A bucket, a key and a blob of bytes with metadata attached — effectively unbounded, reachable from anywhere with credentials, and priced per request as well as per gigabyte. It is the right home for uploads, backups and static assets, and it is not a replacement for a relational database.
Q · Where do large, immutable files live when they must be durable, cheap and reachable from every part of the system?
The application decides who may upload and where, then gets out of the way: the client sends the bytes straight to object storage with a short-lived signed authorization. Your servers authorize the transfer without ever carrying it.
Q · How does a client upload a 500 MB video without that traffic passing through — and tying up — the application servers?
A virtual disk attached to one instance: fixed-size blocks, random writes, a filesystem on top and a database on top of that. It is the only contract that gives a storage engine what it needs — and the only one that can fill up.
Q · What kind of storage does a database need, and why can it not be a bucket or a network share?
A real filesystem, exported over a network, mounted by several machines at once. It is the contract you choose when software demands a path and you cannot change the software — and every filesystem operation is now a network call.
Q · When several machines must see the same files at the same time, what does a shared filesystem actually give you and what does it charge?
Four questions decide it: do you need filesystem semantics, raw disk-like access, massively scalable blobs, or several machines sharing files? Each answer comes with what it costs you, because a recommendation without a trade-off is not a recommendation.
Q · Given how this data is written and read, which storage contract is right — and what does that choice cost me?
The provider runs the process, the volume, the backups, the patching and the failover. You still own the schema, the queries, the indexes, the access control, the instance size and the bill. Managed moves the boundary; it does not remove your half.
Q · When I use a managed database, which operational work has actually gone away — and which work is still mine?
Less infrastructure burden against more control and more operational responsibility. The decision turns on expertise, customization needs, cost at your scale and how much operational risk the team can absorb — and there is no universal winner.
Q · Should this database run as a managed service, or on infrastructure we operate ourselves?