MongoDB Atlas vs Supabase free tier: 512 MB each, different meters

The two free tiers most small products start on are closer than the marketing suggests: half a gigabyte of database, shared compute, no card. What separates them is the meter each vendor puts on the plan, and that meter decides which one you outgrow first.

Atlas gives 512 MB and 100 operations per second. Supabase gives 500 MB, unlimited API requests, 50,000 monthly active users and 5 GB of egress. Both are $0, and both have a first paid step under $30 a month.

What each free tier includes

Atlas's free card in the pricing table lists storage, RAM and vCPU; the throughput and sort ceilings come from the FAQ, and the 500-connection cap comes from the free-cluster documentation rather than the pricing page.

What the two vendors are actually metering

Atlas meters the database engine. Every tier from M0 to M60 is priced by storage, RAM and vCPU, and the free tier is simply the smallest allocation with a throughput ceiling of 100 operations per second. That means the free tier's failure mode is mechanical: the query that needs a collection scan, the aggregation that sorts more than 32 MB, the deploy that opens too many of its 500 connections.

Supabase meters the application around the database. API requests are unlimited on Free, which sounds like the absence of a meter until you read the rest of the card: 50,000 monthly active users, 5 GB of egress, 5 GB of cached egress, 1 GB of file storage, and a limit of 2 active projects. The database itself is 500 MB of disk on shared CPU with 500 MB of RAM, and a free project is paused after a week of inactivity.

So the units are not comparable. Atlas sells operations; Supabase sells identity and bandwidth and treats the database as a fixed allowance inside them. A read-heavy API with few users hits Atlas's wall first. A consumer app with many signups and modest queries hits Supabase's.

How we measured it

Every figure is copied from the Atlas pricing page, the Atlas free-cluster limitations page and the Supabase pricing page, all opened on 2026-10-25. Nothing was provisioned and no benchmark was run. Where a vendor does not print a number on the page, the table says so rather than estimating it, which is why egress is blank on the Atlas side and the project limit is blank on Atlas too.

What changes in practice

The 500 MB Supabase database is the tighter constraint for a product with content in it, because Postgres indexes and WAL live in the same allowance. The 512 MB Atlas database is equally tight, but Atlas users typically scale storage in steps: M2 is 2 GB for $9 a month, M5 is 5 GB for $25.

Supabase's inactivity pause is the one clause people discover late. A free project that gets no traffic for a week is paused, which is fine for a demo and awkward for a staging environment a client is meant to open on a Monday.

Neither free tier includes the thing that usually ends the free period: sustained traffic. Supabase's 5 GB of egress covers about 50,000 responses at 100 KB each (calculated 2026-10-25), and Atlas's 100 operations per second covers a lot of small indexed reads and very few scans. The asymmetry to check before committing is that Supabase meters egress on its free card while the Atlas free card lists no traffic allowance at all.

Bottom line

For a prototype with a handful of users and a relational schema, Supabase Free is the better fit: 500 MB, no per-request metering and a $25 step up that includes compute credit. For a document workload with predictable small queries, Atlas M0 is cheaper to start and $9 buys four times the storage — but plan the exit at 100 operations per second, not at 512 MB.