Storage is the least interesting number
Almost every free Postgres tier gives you more disk than a side project will ever fill. Judging providers on gigabytes is how people end up on a plan that suspends their database after a few days of inactivity.
The numbers that decide whether a free database works for you are the idle policy, the connection ceiling and the backup retention. All three usually sit a click or two below the pricing page.
Idle suspension is the one that bites
Most free tiers pause a database that has not been queried for some window. Waking it adds latency to whichever unlucky request arrives first — usually several seconds, occasionally a timeout if your pool gives up before the database is back.
For a project you are actively building this is invisible. For a demo you show a client once a month, it means the first page load fails. Know which you are building before you pick.
Connection limits and serverless are a bad pair
A generous free tier with a small connection ceiling behaves badly behind serverless functions, because every cold invocation wants its own connection. The result is connection-limit errors under exactly the traffic spike you wanted to celebrate.
If your app is serverless, a provider with pooling built in is worth more than one with ten times the storage. This is the most common way a free database setup fails in production.
- Check the idle timeout before the storage figure.
- Check whether pooling is included or an add-on.
- Check backup retention — several free tiers keep none at all.
- Check what deletion looks like: suspended, or dropped?
The provider that deletes your database
At least one widely recommended free tier does not merely suspend an inactive database — after a longer window it removes it. The policy is documented and entirely reasonable for a free service. It is also the kind of thing you find out about at the worst possible moment.
Take your own backups. A weekly dump to object storage costs nothing and turns a catastrophic policy into an inconvenient one.
