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

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.