Subtitle: Why I Tried Storing Structured Data in Blobs and What Actually Happened
1. The Hook
Everyone tells you not to use Azure Blob Storage as a database. Naturally, I decided to try it anyway.
I had a use case that didn’t justify spinning up SQL or Cosmos DB just some structured, semi-static JSON data I needed to persist cheaply and access globally. Blob Storage seemed too simple to ignore.
So I asked myself: Could I push Blob Storage to act like a database? Spoiler: it kind of worked.
2. The Concept
Here’s the basic idea:
- Each record is a blob (for example, a JSON file).
- Each container is a logical table.
- The blob name acts as a primary key (like
users/user-123.json). - Blob versioning gives you time-travel or history for free.
A minimal .NET example:
var blob = containerClient.GetBlobClient($"users/{userId}.json");
await blob.UploadAsync(BinaryData.FromObjectAsJson(user));
You can later read it back:
var blob = containerClient.GetBlobClient($"users/{userId}.json");
var data = await blob.DownloadContentAsync();
var user = data.Value.Content.ToObjectFromJson<User>();
No schema, no migrations, no SQL. Just blobs.
3. The Benefits (Why It’s Not Completely Dumb)
- Ridiculously cheap: fractions of a cent per GB.
- Globally replicated: can integrate with CDN.
- Schema-flexible: store any JSON structure.
- Built-in versioning: blob versioning acts like record history.
- Excellent for static or rarely-mutating data: configurations, static datasets, logs, or precomputed AI outputs.
Real-world use case: I stored pre-rendered dashboard snapshots in Blob Storage and served them directly through a CDN. Instant load times, no compute, no database calls.
4. The Pain Points (Why It Is Kinda Dumb)
- No query engine: You can’t filter or search without loading everything.
- No transactions or concurrency handling.
- High latency: Every read/write is a network call.
- Limited atomic operations.
- Metadata scaling: Listing blobs becomes slow and costly after tens of thousands.
At around 50,000 blobs, listing performance dropped noticeably. I ended up adding a lightweight Redis index to keep track of blob keys.
5. The Hybrid Trick
Here’s where it got interesting.
What if Blob Storage isn’t the database, but a tier of one?
For example:
App -> Redis index -> Blob for data payload -> CDN edge cache
This hybrid approach works beautifully:
- Redis stores keys and metadata for fast lookups.
- Blob Storage holds large, immutable payloads.
- CDN handles global caching.
Now you’ve got something fast, cheap, and resilient without pretending Blob Storage is SQL Server.
6. The Verdict
Blob Storage won’t replace your relational database. It’s not built for dynamic queries, transactions, or real-time updates.
But as a cold-storage layer, append-only log, or versioned config repository, it’s surprisingly elegant. And when combined with in-memory indexes or CDN caching, it can punch far above its weight.
Blob Storage isn’t dumb. It’s just misunderstood.
Used wisely, it can make your architecture simpler, cheaper, and more scalable.
7. Optional Extras
If you want to take this further:
- Benchmark upload/download speed with
.OpenReadAsync()and parallel uploads. - Use Azure Functions to auto-index blob metadata.
- Explore Blob Storage versioning for immutable event sourcing.
Final Thoughts
I wouldn’t recommend building your startup’s core database on blobs. But if you have structured, infrequently-changing data that doesn’t need queries it might just be the most underrated trick in Azure.
What do you think? Would you ever use Blob Storage as a database?
Top comments (4)
What you are talking about is NoDB. I did a post about it a while ago.
And there are query engines for it.
Haha, looks like I accidentally reinvented your NoDB idea 😅 Just read your post, love how you broke down the query vs storage split. I was playing with Blob Storage as pure storage, but now I’m tempted to try it with a real query layer like you suggested.
It is not my idea. I discovered it because it was in the Lobsters feed.
Ah, makes sense! Either way, thanks for pointing me toward it the NoDB concept connects really well with what I was trying to do. Learned something new today 😄