lathe docs

Style

ClassicSystem fonts, slate DeveloperGeist, mono interface TerminalMono everywhere, phosphor

Mode

System Light Dark

What Vercel + Supabase really costs when your app gets traffic

When we started building small products, Vercel plus Supabase looked inexpensive.

It often is at the beginning. Both products have useful free tiers. A small app can run for months without a meaningful infrastructure bill.

Then the app gets actual traffic, another person joins the project, or a customer asks for a feature that sits outside the included quotas.

The bill does not suddenly become bad. It becomes harder to predict.

The two of us kept coming back to the same questions:

So we read the current Vercel and Supabase pricing pages line by line. This is the cost model we found, and why we built Lathe around one machine and one flat bill instead.

Prices below are in USD and were checked on September 21, 2026. Vendor pricing changes, so the linked pages are the source of truth.

The paid stack starts at $45 a month

For a commercial app, the simple starting point is Vercel Pro plus Supabase Pro.

Vercel Pro has a $20 monthly platform fee. That includes one deploying seat, $20 of monthly usage credit, 1 TB of Fast Data Transfer and 10 million Edge Requests. Each additional Owner or Member seat is another $20 a month. Billing is the platform fee, paid seats, add-ons and usage beyond the included amounts.

Supabase Pro starts at $25 a month for an organization. It includes $10 of compute credit, enough for one Micro project. Each extra Micro project adds $10 a month, and larger compute sizes cost more.

That makes the smallest paid Vercel + Supabase stack $45 a month before extra seats, extra projects, add-ons or overages.

For one founder, that can be a good deal. For a three-person team with all three deploying to Vercel, the Vercel side becomes $60 before usage: the $20 platform fee plus two additional $20 seats. Add Supabase Pro and the starting bill is $85.

The important word is starting.

Traffic is two different meters

A request to an app can cross both platforms.

Vercel serves the application and its assets. Supabase returns database rows, auth responses, files, realtime messages or function output. Each platform measures its own traffic.

On Vercel Pro, the first 1 TB of Fast Data Transfer and 10 million Edge Requests are included. After that, Vercel's regional pricing lists Fast Data Transfer at $0.15 to $0.35 per GB and Edge Requests at $2.00 to $3.20 per million, depending on region. The included $20 usage credit is applied before on-demand charges.

On Supabase Pro, the pricing page includes 250 GB of uncached egress and 250 GB of cached egress. They are separate quotas. Above them, uncached egress is $0.09 per GB and cached egress is $0.03 per GB. Supabase explains that egress can come from Database, Auth, Storage, Edge Functions, Realtime and Log Drains in its egress guide.

That distinction matters. "We transfer 300 GB a month" is not enough information to predict the Supabase bill. You need to know how much is cached and which services are producing it.

Supabase's own example makes this concrete. One Pro organization on Small compute with 300 GB of uncached egress and 800 GB of cached egress totals $51 after its compute credit: $25 for Pro, $15 for Small compute, $4.50 of uncached overage and $16.50 of cached overage, minus $10 of compute credit.

No individual line is shocking. The work is knowing which lines your product will create.

Usage does not stop at bandwidth

Traffic is only the most visible meter.

Vercel also prices build CPU time, image transformations, cache operations, Blob storage and transfer, observability and other infrastructure separately. The current pricing reference lists build usage at $0.0035 per CPU minute. The exact rate for many runtime and delivery resources depends on region.

Supabase Pro includes generous quotas, then charges by dimension. Its pricing page currently lists:

A product rarely crosses every limit at once. That is not the point.

The point is that actual traffic turns one architecture into several independent pricing questions. A quiet database-heavy product and a file-heavy product can have the same user count and very different bills.

A launch month is hard to model from user count

Suppose a small product has one founder, one production project and ordinary traffic. Its paid floor is $45 a month.

Now suppose a launch pushes Vercel Fast Data Transfer to 1.5 TB in a region charging $0.15 per GB. Roughly 500 GB sits above the included 1 TB, creating about $75 of usage before the $20 monthly credit is applied. The Vercel portion moves from $20 to about $75 for that simplified example.

If the same month also puts Supabase at 500 GB of uncached egress, 250 GB is above its included quota. That adds $22.50.

The combined bill is now about $122.50 rather than $45, before any other compute, request, storage or add-on charges.

This is not a forecast for every app. It deliberately leaves out regional differences, cached traffic, request charges and other meters. It is an example of why "we have this many users" does not answer "what will infrastructure cost?"

Vercel and Supabase both offer spend controls and usage dashboards. Those are useful. They also become another part of operating the product: set budgets, watch the meters, decide whether to optimize or pay, and understand what a limit will do to production.

What we built instead

Lathe puts the app, Postgres, auth and optional Redis, CouchDB and NATS on one dedicated machine.

Plans are $15, $29, $49 and $89 a month. The plan price is based on machine size.

We do not add a line item for:

A workload may outgrow its machine and need a larger plan. That changes the monthly price from one known number to another known number. It does not turn each part of the stack into a separate meter.

Lathe itself runs on Lathe. The site, portal and API use the same application and database path customers use. If that path breaks, we feel it first.

Flat does not mean infinitely scalable

A useful pricing comparison should say what the cheaper-looking number does not buy.

Each Lathe instance is one machine. That is the feature and the limit.

Lathe is not the right fit if you need:

Vercel and Supabase can absorb shapes of growth that one machine cannot. Their metering is connected to that model. If sudden global scale matters more than a fixed bill, paying for that architecture can be the right decision.

A mostly idle project may also be cheaper on free tiers than on any paid machine. We are not claiming that $15 always beats $0.

We are saying that a product which already needs a paid app, a paid database and predictable production behavior deserves a second calculation.

A practical cost checklist

Before choosing Vercel + Supabase, estimate:

Vercel + Supabase is probably the better fit when:

A managed dedicated machine is worth considering when:

Start with your own last 30 days

Do not migrate based on a hypothetical bill.

Take the last 30 days from both dashboards. Add the Vercel platform fee, seats and usage. Add the Supabase plan, project compute, egress, storage, users and add-ons. Then model one ordinary month and one launch month.

Compare those totals with the machine size the same workload would need. Include the architectural differences, not just the price.

We published a complete Next.js guestbook guide showing the app, database and auth flow on Lathe. There is also a broader guide to replacing Vercel + Supabase without becoming full-time DevOps.

Lathe has a 14-day trial with no card. Put a real side project on it, watch the machine under traffic and decide from evidence.

The point is not that usage pricing is dishonest. The vendors publish the numbers, and the model funds capabilities many products need.

The point is that once an app gets traffic, the real cost is the sum of the platform fee, people, projects, traffic and feature-specific meters. We wanted an option where that sum is one number.

Try the one-machine model on a real project.

14 days, no card. Cancel any time.

Start free - 14 days, no card needed