Blob, File, Queue or Table: which storage service do you need?
People say "Azure Storage" as if it is one thing, but a storage account hands you four separate data services — and reaching for the wrong one turns a five-minute task into a week of regret.
New to cloud? CAMPUX is a free, build-first course. Start here →
When you create a storage account, you do not get a bucket. You get four doors: Blob, File, Queue, and Table. They share the account's name, its keys, its encryption at rest, and its redundancy setting, but each is a different service with a different shape and a different job. Microsoft groups them under one platform because they share plumbing, not because they are interchangeable. Learn what each one is for and the choice becomes obvious in a sentence. Confuse them and you end up jamming a message queue into a table, or serving images off a file share, and paying for the mistake in latency and cost.
Blob — objects, and lots of them
Blob is object storage for unstructured data: images, video, backups, logs, PDFs, static site assets, anything you think of as a file that a program reads or writes whole. Each blob gets a URL, so a browser or an app can pull it straight over HTTPS. This is the door you reach for most. When your app lets users upload profile pictures, they land in Blob. When a nightly job dumps a database backup, it goes to Blob. When you build a data lake for analytics, that is Blob with Data Lake features turned on. If the thing you are storing is a file that no other service needs to mount like a drive, Blob is the answer. It also has access tiers — hot, cool, cold, archive — so rarely-touched data costs a fraction of what live data does.
The trap is treating all four as one bucket. They are four services that happen to share a front door — pick by the shape of your data, not by the name on the account.
File — a shared drive you can mount
Azure Files gives you a fully managed network file share you mount over SMB (or NFS), the same protocol Windows and Linux already speak to file servers. The difference from Blob is the word mount: a File share shows up as a drive letter or a path, and several VMs can read and write it at once. You reach for File when you are lifting an old application into the cloud that expects a shared drive — the kind that reads a config file off \\server\share and writes logs back to it. Point it at an Azure Files share instead and the code barely changes. It is also where you park tools, config, and crash dumps that a fleet of machines all need to see. Blob is for objects your app fetches by URL; File is for a filesystem your app opens by path.
Queue — decouple the parts that should not wait on each other
Queue Storage is a simple message store. One part of your app writes a small message (up to 64 KB); another part reads it and does the work later. That gap in time is the whole point. The classic case: a user uploads a photo and you need to generate thumbnails. You do not make them wait while the resizing runs. The web tier drops a message on the queue and returns immediately; a worker process picks the message up and does the resizing on its own schedule. Now the web tier and the worker scale independently, and a burst of uploads becomes a growing backlog instead of a pile of timeouts. You reach for Queue whenever you want to decouple a web front end from background work — this is the Web-Queue-Worker pattern, and Queue Storage is the cheap, no-frills way to build it.
Table — cheap structured NoSQL
Table Storage is a key-value store for structured but non-relational data. No joins, no schema enforced across rows, no SQL — just a partition key, a row key, and whatever properties you attach. You reach for it when you have a lot of simple structured records and want them stored dirt cheap: user profiles for a web app, device readings, address-book entries, per-object metadata. It is fast for point lookups by key and priced to hold enormous piles of rows. One thing to know going in: for anything that needs global distribution, single-digit-millisecond latency, or secondary indexes, Microsoft now points you at Azure Cosmos DB for Table, which speaks the same API but scales far past what basic Table Storage was built for. Start on Table for cheap and simple; graduate to Cosmos DB Table when scale demands it.
Ask what shape the data is. Files an app reads whole or serves by URL — Blob. A drive several machines need to mount by path — File. Small messages handed from one component to another to break them apart — Queue. Piles of simple structured records you look up by key on the cheap — Table. Blob is the default and the one you will use most; the other three answer a specific need, and if none of those needs is yours, it is Blob.
The takeaway
Blob, File, Queue, and Table all live inside one storage account, share its keys and its encryption, and get billed under its name — but they are four services for four different jobs. Blob holds objects: images, backups, logs, static assets, data lakes. File is a mountable SMB share for lifting a legacy app's shared drive into the cloud. Queue passes small messages so a web tier and a worker stop waiting on each other. Table is cheap structured NoSQL for piles of simple records, with Cosmos DB for Table waiting when you outgrow it. Pick by the shape of the data, not the name on the account, and you will reach for the right door every time. If you want the account itself — its types, tiers, and redundancy — start with the storage account types.
Questions people also ask
What is the difference between Blob and File storage in Azure?
Blob stores objects — images, backups, logs — that an app reads or writes whole and fetches by URL over HTTPS. File gives you a managed network share you mount over SMB or NFS, so it shows up as a drive letter or path that several machines read and write at once. You pick Blob for objects, File for a mountable filesystem a legacy app expects.
What is Azure Queue storage used for?
You use Queue storage to hold small messages — up to 64 KB each — so one part of your app hands work to another that runs later. It decouples a web front end from background workers, letting each scale on its own and absorbing traffic bursts as a backlog instead of timeouts. It is the plain, cheap way to build the Web-Queue-Worker pattern.
Is Azure Table storage the same as Cosmos DB?
No. Table storage is cheap key-value NoSQL where you pay only for what you use, with a 10-second SLA and a per-account size limit. Cosmos DB for Table speaks the same API but adds single-digit-millisecond latency, global distribution, automatic secondary indexes, and petabyte scale on a reserved-capacity price. You start on Table and move to Cosmos DB when scale demands it.
Do Blob, File, Queue and Table share one storage account?
Yes. When you create a storage account you get all four services under one name. They share the account's access keys, its encryption at rest, and its redundancy setting, but each is a separate service with its own shape and job. Microsoft groups them because they share plumbing, not because you can swap one for another.
Which Azure storage service should you use by default?
You reach for Blob most of the time. It holds any file an app reads whole or serves by URL — uploads, backups, logs, static assets, data lakes. File, Queue and Table each answer a specific need: a mountable share, message passing between components, or cheap structured records looked up by key. If none of those needs is yours, the answer is Blob.