Cosmos DB vs Firestore: A Free-Tier Operations Ledger on Both Clouds
Every real content operation grows a small database it didn’t plan for: a ledger of what got published when, a metadata store tracking which article has an audio version, which has been translated, which is queued. It’s not big data — it’s a few thousand small records that need to be written cheaply, queried quickly, and never cost anything. The question is which cloud’s free NoSQL tier carries that load forever.
We run the same small ops ledger and content-metadata store on both Azure Cosmos DB and Google Firestore, on the free tiers, and watch the quotas. Short answer: Cosmos DB’s always-free tier is unusually generous — 1,000 RU/s of provisioned throughput plus 25 GB of storage, free for the life of one account per subscription. Firestore’s free tier is simpler but tighter — 1 GiB of storage with 50,000 reads, 20,000 writes, and 20,000 deletes per day. For a metadata store that fits either, Cosmos gives you more room; Firestore gives you less to think about.
This is the breakdown from the running lab on tygart.media — free-tier generosity, data model, query power, latency, and which one we’d trust with the ledger.
The free-tier ceilings
This is where the two diverge most, and the units don’t line up cleanly — which is itself the point.
How we do it
| Azure | Google Cloud | Verdict | |
|---|---|---|---|
| Free throughput | 1,000 RU/s provisioned | 50K reads / 20K writes / 20K deletes per day | Cosmos for steady throughput |
| Free storage | 25 GB | 1 GiB | Cosmos — 25× the storage |
| Billing unit | Request Units (RU/s) | Per-operation daily quota | Different mental models |
| How many free tiers | One per subscription | Per project (Spark plan) | Tie, structurally |
| Fit for a metadata store | Generous | Comfortable for small stores | Cosmos on headroom |
The mismatch in units is the real story. Cosmos meters everything in Request Units — a blended currency for reads, writes, and queries — and gives you a flat 1,000 RU/s continuously plus 25 GB. Firestore meters discrete daily operations — 50K reads, 20K writes, 20K deletes — and 1 GiB. For our ledger, Cosmos’s 25 GB is absurd headroom we’ll never approach, and 1,000 RU/s comfortably absorbs bursty publish events. Firestore’s daily caps are fine for a small store but you feel them: a chatty dashboard that re-reads the ledger on every page load can nibble through 50K reads faster than you’d expect.
Data model and query power
How we do it
| Azure | Google Cloud | Verdict | |
|---|---|---|---|
| Data model | Multi-model (document, key-value, graph, column) | Document (collections + docs) | Cosmos on flexibility |
| API surface | NoSQL (SQL-like), MongoDB, Cassandra, Gremlin, Table | Native Firestore SDK | Cosmos on portability |
| Query model | Rich SQL-like queries, indexing tunable | Indexed queries, real-time listeners | Tie — different strengths |
| Real-time sync | Change feed | First-class real-time listeners | Firestore on live UI |
| Schema | Schema-agnostic | Schema-agnostic | Tie |
Cosmos is multi-model: the same data can be addressed through a SQL-like NoSQL API, MongoDB’s wire protocol, Cassandra, Gremlin (graph), or Table. If you ever want to query the ledger like a graph, or you’re migrating off MongoDB, that optionality is real and free. Firestore is single-purpose by design — document collections with excellent real-time listeners, which is the thing to reach for when a dashboard should update live as the ledger changes. For a metadata store feeding a UI, those listeners are genuinely pleasant.
Latency and operational feel
How we do it
| Azure | Google Cloud | Verdict | |
|---|---|---|---|
| Read latency | Single-digit ms (tuned) | Low, very consistent | Tie at our scale |
| Provisioning model | Provisioned RU/s (or serverless) | Fully managed, no capacity knobs | Firestore on simplicity |
| Capacity tuning | You can over/under-provision | Nothing to tune | Firestore on hands-off |
| Setup friction | A few more knobs | Near-zero | Firestore |
At our volume, both are fast enough that latency never registered as a difference. The operational feel diverges: Cosmos hands you knobs (RU/s, consistency levels, indexing policy) — power if you want it, a thing to learn if you don’t. Firestore has almost no knobs, which is the right call when the database is a side character in your stack and you never want to think about capacity.
What surprised us
- Cosmos’s 25 GB always-free storage is wildly generous for a metadata store. We will not approach it. It reframed Cosmos from “enterprise database” to “perfectly viable free tier.”
- Firestore’s daily read quota is the thing to watch. It’s not the storage that bites — it’s a chatty UI re-reading the ledger. Cache reads or you’ll surprise yourself.
- The RU/s model has a learning curve. Cosmos’s Request Unit currency is unintuitive at first; once it clicks, capacity planning is straightforward, but day one is more conceptual than Firestore.
- Firestore’s real-time listeners are a quiet joy. For a live dashboard, “the data just updates” without polling is worth a lot.
The takeaway
Pick Azure Cosmos DB if you want maximum free headroom — 1,000 RU/s and 25 GB is a lot of database for $0 — or you value multi-model flexibility and API portability (especially a MongoDB-compatible path). It’s our pick when the ledger might grow or change shape.
Pick Firestore if you want the simplest possible managed document store with first-class real-time listeners and nothing to tune, and your store stays comfortably inside 1 GiB and the daily operation caps. It’s the right call when the database should disappear into the background.
For our ops ledger, Cosmos’s always-free generosity is hard to argue with — but for the live dashboard that reads the ledger, Firestore’s real-time listeners are the nicer developer experience. Running the same store on both made the trade explicit instead of theoretical.
This is part of our “Two Clouds, One Site” series — we run the same media property on both Azure and Google Cloud on the free tiers, keeping the same ops ledger on each to see where the quotas really pinch. The lab lives on tygart.media; the findings publish here.
Frequently asked questions
What does the free tier of Cosmos DB and Firestore actually include?
Azure Cosmos DB’s always-free tier gives 1,000 RU/s of provisioned throughput plus 25 GB of storage, free for one account per subscription. Firestore’s free Spark tier gives 1 GiB of storage with 50,000 reads, 20,000 writes, and 20,000 deletes per day. Cosmos offers far more storage; Firestore meters by daily operations.
Is Cosmos DB or Firestore more generous on the free tier?
For storage and steady throughput, Cosmos DB is more generous — 25 GB and a continuous 1,000 RU/s versus Firestore’s 1 GiB and daily operation caps. Firestore is perfectly adequate for a small metadata store, but a chatty application can hit its daily read quota. Cosmos gives more headroom for growth.
What’s the difference between Cosmos DB and Firestore’s data model?
Cosmos DB is multi-model: the same data can be queried as documents, key-value pairs, graphs, or columns, and it speaks NoSQL, MongoDB, Cassandra, Gremlin, and Table APIs. Firestore is a focused document database — collections and documents — with excellent real-time listeners. Cosmos offers flexibility; Firestore offers simplicity.
Which is better for a serverless content metadata store?
Both work well. Choose Cosmos DB if you want generous free storage, multi-model flexibility, or a MongoDB-compatible path. Choose Firestore if you want a zero-tuning managed store with real-time listeners that update a dashboard live, and your data fits inside 1 GiB and the daily operation limits.
Will I hit Firestore’s free quota with a small app?
Storage usually isn’t the problem — 1 GiB holds a lot of small records. The daily read quota of 50,000 is what catches people: a dashboard that re-reads the same data on every page load can consume it quickly. Caching reads keeps a small app comfortably inside the free tier.
Leave a Reply