A free tier is a marketing budget with a shutoff valve, and the valve is placed on whatever metric grows when your project starts working. The trap is rarely the price you eventually pay — it's that the flip arrives on the vendor's schedule, not yours, usually as a hard stop rather than a slow ramp. The practical defense is to know which dimension each vendor meters, and to keep the two or three pieces that would be painful to move sitting behind an interface you control.
I've had a side project paused, a database run out of connection slots on a Sunday, and a CI pipeline stop mid-release because the month's minutes were gone. None of those were surprises in hindsight. All of them were surprises at the time.
Why do vendors give away a free tier at all?
There are only a few reasons a company hands you compute for nothing, and each one produces a different shape of limit.
Acquisition funnels. The free tier exists to get a credit card on file eventually. These are usually generous on the dimension you notice (deploys, projects, requests) and tight on the dimension that costs the vendor money (bandwidth, storage, seats). They're stable for years because the free users are the pipeline.
Developer mindshare. The vendor wants you to reach for them at work. Limits here tend to be per-project rather than per-account, and the friction is deliberately placed at team features — SSO, roles, audit logs, shared environments — not at raw capacity.
Capacity dumping. Sometimes free tier is just idle infrastructure being monetized as attention. This is the least stable category, because when the underlying economics move, the tier moves with them.
Open core. The free thing is the software, not the hosting. These flip in a different way: the product stays free, but the feature you now depend on migrates into an enterprise edition.
That last distinction matters more than most people weigh it. A hosted free tier can be withdrawn overnight; a permissively-licensed open source project can only be forked away from you slowly, and you keep the running copy either way.
Takeaway: figure out which of the four reasons you're benefiting from, because it predicts how much notice you'll get.
What actually flips a hobby plan to paid?
The flip almost never comes from the metric in the marketing table. It comes from a second-order metric you weren't tracking.
| Flip trigger | What it looks like in practice | Warning you get |
|---|---|---|
| Sustained egress/bandwidth | One image-heavy page gets linked somewhere | Usually an email, sometimes after the fact |
| Compute-seconds, not requests | A slow endpoint or an N+1 in a background job | Dashboard graph you have to look at |
| Concurrent connections |
remaining connection slots are reserved at the worst time |
None — it's a hard error |
| Inactivity | Project auto-paused after days of no traffic | Notification you'll miss |
| Rows / storage growth | A logging or events table nobody prunes | Gradual, then a write failure |
| Seats | You add one collaborator | Immediate paywall |
| Policy change | The tier itself is retired | Weeks to months of notice |
The connection-limit case is the one that ruins weekends. On a small managed Postgres, the connection ceiling is low and serverless functions each want their own connection, so a modest traffic bump produces:
FATAL: remaining connection slots are reserved for non-replication superuser connections
This is not a "you've grown, please upgrade" message. It's an outage. The fix is a pooler, not a plan upgrade — and knowing that difference is worth real money.
// Pool once per process, not per request. In serverless, cap it hard
// and point at the pooler endpoint, not the direct database host.
import { Pool } from 'pg'
const pool = new Pool({
connectionString: process.env.DATABASE_URL, // pooler URL (often port 6543)
max: 1, // one connection per function instance
idleTimeoutMillis: 10_000, // release fast so instances don't hoard slots
connectionTimeoutMillis: 5_000 // fail fast instead of piling up
})
export async function query(text, params) {
const client = await pool.connect()
try {
return await client.query(text, params)
} finally {
client.release()
}
}
If your platform's free tier gives you a pooled connection string, use it from day one even when you don't need it. Migrating to it under load is a much worse afternoon.
Takeaway: the limit that stops you is the one that isn't on the pricing page.
Which limits bite first, by service category?
As of mid-2026 the patterns below hold across most vendors in each category, though the specific numbers change constantly — always check the current pricing page rather than trusting a number you read in a blog post, including this one.
| Category | Metered dimension that bites | Typically fine on free tier | Move-off signal |
|---|---|---|---|
| Static/edge hosting | Bandwidth, build minutes, commercial-use clause | Personal sites, docs, demos | Any revenue-generating traffic |
| Managed Postgres | Connections, storage, inactivity pausing | Prototypes, low-write apps | Background jobs + real users |
| Serverless functions | GB-seconds and cold-start behavior | Sporadic traffic | Anything with steady load |
| CI | Minutes/month, concurrency | Small repos, few branches | Matrix builds, monorepos |
| Error tracking | Event volume, retention window | Early apps | Any noisy dependency |
| Auth | MAU threshold, and which features sit above it | Single-app, single-tenant | Orgs, SSO, custom domains |
Two specifics worth naming. Cloudflare's free tier is the most durable in the static/edge category because its economics come from network scale rather than from converting hobbyists, but its worker runtime is genuinely different from Node and porting is real work. Supabase's free tier is the most complete "whole backend" offer, but free projects pause after a stretch of inactivity — fine for a portfolio piece, disqualifying for anything a client might open unannounced.
Also, read the commercial-use language. Several excellent free tiers are explicitly for non-commercial or personal projects, and the moment your side project takes payments you are out of compliance regardless of usage volume.
Takeaway: pick the free tier whose metered dimension is the one your app grows slowest on.
How do you know a free tier is about to disappear?
History gives a usable prior. Heroku retired free dynos in late 2022, Railway replaced its free tier with a trial in 2023, and PlanetScale removed its hobby tier in 2024 — each after a period where the free plan was visibly the most-discussed thing about the product. The pattern is consistent: free tiers get withdrawn when the company shifts from growth-at-any-cost to gross-margin discipline, which for infrastructure vendors tends to follow a funding round or an enterprise push.
Signals I now treat as a soft deadline:
- The free tier stops being mentioned in launch posts and docs quickstarts.
- Support responses start routing free users to community channels only.
- A "usage-based" plan appears below the old paid plan — the free tier is being repriced, not removed, and it's next.
- The company announces enterprise features (SSO, compliance certifications) as its main roadmap theme.
None of these are proof. All of them are enough to spend an hour making sure you could leave.
Takeaway: when a vendor stops marketing its free tier, start planning like it's already gone.
What does a portable setup actually look like?
You don't need multi-cloud abstraction. You need three things checked before you build on any free tier:
-
Can I export my data unassisted? A
pg_dump-compatible database or an S3-compatible bucket is portable. A proprietary document store with an export button that emails you a link is not. - Is the runtime standard? Code that runs on plain Node/Python containers moves in an afternoon. Code written against a vendor-specific runtime, KV store, or auth SDK moves in a sprint.
- Is config in the repo? If redeploying elsewhere means recreating settings you only ever clicked into a dashboard, you don't have a project, you have a pet.
Concretely, keep vendor SDKs behind a thin module of your own — one file with getUser(), sendEmail(), putObject() — so the blast radius of a pricing change is a file, not a codebase. This costs an hour up front and it's the single highest-return hour in a side project.
You can also just watch your usage. Most platforms expose it via API, so a weekly check costs nothing:
#!/usr/bin/env bash
set -euo pipefail
# GitHub Actions minutes for the authenticated user (endpoint as of mid-2026;
# verify against current REST docs if it 404s).
gh api /users/"$(gh api /user --jq .login)"/settings/billing/actions \
--jq '"used: \(.total_minutes_used)/\(.included_minutes) minutes"'
Wire that into a weekly cron or a CI job and the flip stops being an ambush.
Takeaway: portability is a property of your export path and your runtime, not of your provider's promises.
FAQ
Is it safe to build a real product on a free tier?
Build on it, yes; depend on it, no. Use the free tier for the prototype and the pre-revenue phase, but only if the data export path and the runtime are standard enough that you could move in a day. The moment the project takes payments, budget for the paid plan and check the free tier's commercial-use terms.
Why did my free tier database suddenly stop accepting connections?
Almost always the connection ceiling, not storage. Serverless functions open a connection per instance, so a small traffic spike exhausts the slots and you get remaining connection slots are reserved for non-replication superuser connections. Switch to the provider's pooled connection string and cap max at 1 per instance before you consider upgrading.
Which free tiers are the most stable long-term?
The ones where free users cost the vendor almost nothing relative to its scale, or where the free thing is open source software you can self-host. Free tiers offered as an acquisition funnel by a venture-funded startup are the least durable, because their economics depend on a conversion rate that has to improve eventually.
Bottom line
If you're building a portfolio project or a prototype, take the most generous free tier you can find and don't think about it — that's what it's for. If you're building something that might make money, choose based on the metered dimension: pick the vendor whose meter runs on whatever your app produces least. If your project already has users who'd notice an outage, pay for the database and the error tracking first, since those are the two places where a free-tier limit turns into a hard failure rather than a slowdown. And regardless of tier, spend the hour on exports and a thin vendor wrapper — it's cheap insurance against a pricing email you didn't ask for.
Top comments (0)