A free hosted PostgreSQL tier is a real Postgres instance with real limits attached: a storage cap that is usually small, a hard ceiling on concurrent connections, and in many cases a clock that pauses or deletes the database if nothing connects for a while. None of that makes a free tier useless, but it does make it a poor fit for anything beyond a prototype, a learning project, or a service with genuinely low, steady traffic. Reading a free-tier page correctly means checking four things before signing up: the storage ceiling, the connection ceiling, whether the instance sleeps or expires on inactivity, and how backups are handled, because free rarely includes disaster recovery.
Free Postgres offers show up in search constantly because the search itself is a signal: someone is prototyping, learning, or trying to avoid a credit card before they know whether the project survives its first week. That is a reasonable thing to want. This post covers what the common limits actually are, why they exist, and what changes once a project needs to be trusted with real traffic, without quoting any specific competitor’s numbers as though they were fixed.
Table of contents
- Storage and connection caps, and why they exist
- Sleeping, pausing and expiry: read the fine print
- No credit card required is not the same as no limits
- Backups on a free tier: usually your job
- A framework for judging any free Postgres offer
- Our Free plan for Postgres, plainly
- When a free tier is the wrong tool
- How this fits the rest of the stack
- FAQ
Storage and connection caps, and why they exist
Free Postgres tiers typically cap storage somewhere between a few hundred megabytes and a couple of gigabytes, and cap concurrent connections in the single digits to low tens. These are not arbitrary; a free tier runs on shared, cost-constrained hardware, and the caps exist to keep one account’s spike from degrading everyone else sharing that hardware. Understanding this framing matters more than the specific numbers, because it explains why the limits tighten rather than loosen as a free tier matures: the provider is protecting a resource it is giving away.
The storage cap is usually the easier of the two to plan around, since most prototypes and small projects genuinely fit inside a few hundred megabytes for a long time. The connection cap is the one that surprises people, because it is not about how much data you store but about how many things are talking to the database at once, and a handful of serverless functions or a burst of concurrent users can hit a single-digit connection ceiling far sooner than the storage limit ever comes up.
Sleeping, pausing and expiry: read the fine print
This is the gotcha that catches the most people. Many free databases pause after a period of inactivity, commonly somewhere between a few minutes and a few days, and take a noticeable cold-start delay, sometimes several seconds, to wake back up on the next connection. Some go further and expire entirely after a fixed number of days, requiring the database to be recreated from scratch. A smaller number will delete data outright once the trial period ends. This is the single biggest reason free quietly becomes temporary: a database that works fine in testing can appear broken in production the moment traffic goes quiet for an hour and the next request hits a cold, unresponsive connection.
Expiry is worse than pausing because it is not always reversible from the application’s point of view. A paused instance wakes back up with the same data once a connection arrives; an expired one may require a fresh database with a new connection string, which means updating every environment variable that pointed at the old one and, if there was no recent export, losing whatever was stored. Reading the specific inactivity window and expiry policy on the plan you are about to use takes a few minutes and avoids finding out the hard way.
No credit card required is not the same as no limits
Marketing copy draws a real distinction between free, no card required and a free tier of an otherwise paid product, and it is worth reading which one you are looking at. The former often carries the tightest caps, precisely because the provider has no billing relationship to fall back on if usage spikes unexpectedly; there is no upgrade path mid-session, only a hard limit. A free tier attached to a paid product, by contrast, usually has a clearer, single-click path to more resources the moment you need them, which is worth factoring in even if the free limits themselves look similar on paper.
It is also worth noticing which model a given provider is running before you build anything on it, because the two behave very differently the moment a project starts to grow. A no-card-required free database that suddenly needs more storage or connections may have nowhere to go without a full migration, while a free tier of a paid product usually lets you upgrade the exact same database in place, keeping the same connection string and the same data.
Backups on a free tier: usually your job
Automated backups and point-in-time recovery are commonly features reserved for paid tiers. On a free plan, the safety net, if there is one, is usually a manual pg_dump you run and store yourself on a schedule you remember to keep. This is worth internalizing before treating a free database as anything more than disposable: if the provider does not advertise automated backups on the free plan, assume there are none, and export accordingly.
A framework for judging any free Postgres offer
The same short checklist applies regardless of which provider’s free-tier page you are reading.
- What is the storage ceiling in gigabytes, and how close is your expected data to it
- What is the connection ceiling, and does your app’s expected concurrency fit under it
- Does the instance sleep, pause, or expire on inactivity, and after how long
- Is a manual export the only real backup, or are automated backups included
- Is there a clear, priced upgrade path once the project outgrows the free tier
Our Free plan for Postgres, plainly
RunxBuild’s Free plan runs a managed Postgres instance at 0.1 vCPU and 512MB of RAM, available for 15 free days each month, after which it continues at $1.80 if you keep it running. It is a sized-down instance of the same managed Postgres described in the database docs, with the same backups, private networking, and connection-limit handling as the paid tiers above it, not a stripped demo with different rules. The upgrade path when a project outgrows it is a plan change rather than a migration to a different product, which matters if the free-tier evaluation above led you to a provider where growing out of free means starting over somewhere else.
When a free tier is the wrong tool
A free Postgres tier is the wrong choice the moment real users depend on the data being there, the moment a pause-and-cold-start delay would be visible to them, or the moment expected concurrent connections exceed what the tier allows. It is the right choice for exactly what it is built for: prototyping an idea, learning SQL, or running a genuinely low-traffic side project where an occasional cold start is a non-issue rather than an incident. Guides like Railway Postgres and Prisma Postgres are useful references for how other hosted Postgres setups approach the same tradeoffs.
How this fits the rest of the stack
Free is a real starting point for Postgres, not a trap, as long as the storage ceiling, connection ceiling, and sleep-or-expiry behavior are checked before anything depends on them, on any provider you land on. The RunxBuild hosting calculator shows exactly what the free 15 days and the $1.80 after it look like against a real workload, and the database docs cover backups and connection limits at every tier above it, so the upgrade path is visible before you need it rather than after.
Useful related references:
FAQ
Is there a truly free hosted Postgres database?
Yes, several providers offer a genuinely free tier, though the definition of free varies: some require no credit card and cap resources tightly, others attach a free tier to a paid product with a clearer upgrade path. Check storage, connections, and whether the instance sleeps before relying on any of them.
Do free Postgres databases expire or get deleted?
Many do, either pausing after a period of inactivity or expiring outright after a fixed number of days. Some providers delete the underlying data once a trial period ends. Always check the specific provider’s inactivity and expiry policy before storing anything you cannot recreate.
Why do free database tiers pause or sleep?
Free tiers run on shared, cost-constrained hardware, and pausing an inactive instance frees that capacity for other accounts. It also protects the provider from the cost of keeping thousands of idle databases running continuously for no traffic.
How many connections does a free Postgres tier usually allow?
Typically somewhere in the single digits to low tens of concurrent connections, well below what a paid tier allows. This is usually the first limit an app actually hits, often before storage or CPU becomes a concern, especially under any kind of traffic spike.
What happens when I outgrow a free Postgres tier?
It depends on the provider: some offer a straightforward plan upgrade that keeps the same database and connection details, others require migrating to a different product or plan entirely. Check the upgrade path before you build on a free tier, not after you need it.