blob-storelisted

# Blob store Store large, immutable, unstructured objects — images, video, backups, model weights, document blobs — in a flat namespace keyed by a string, replicated for durability and served by direct download. Getting it wrong means stuffing multi-megabyte blobs into a row-oriented database (where they bloat the working set, wreck cache locality, and cap throughput) or hand-rolling a file server that loses data on the first disk failure. ## When to reach for this Objects are large (KB to GB), written once and read many times, and you only ever fetch them whole by key — never query *inside* them. Photo/video stores, user uploads, backups, data-lake/ML datasets, static-site assets, log archives. The access pattern is `PUT key → GET key`, durability matters, and the total volume is too large or too cold to sit in a primary database. ## When NOT to Small structured records you query, filter, sort, or join — that is `data-storage`. Data that needs transactions, secondary indexes, or partial updates (blobs are replace-whole, not edit-in-place). Low-latency reads of tiny values (a KV cache or `caching` wins). A few files on one box that never grow — the local filesystem is fine; a blob store is operational overhead you do not need yet (YAGNI). Naming "object storage" for a workload that is really a database is failure mode #2. ## Clarify first - **Object size distribution** — average and p99 size? (Decides chunking, multipart thresholds, and whether reads stream or buffer.)