free-cloud-database

Choosing a free cloud database is not a features problem. Every engine in the shortlist can store your rows. What differs is which one stops being free, or stops being appropriate, at the exact moment your project changes shape — and that depends entirely on what you are building.

So this guide is organised by situation rather than by product. Find the paragraph that describes your week and read that one. Each ends with something you can act on.

Which of these are you?

• A side project you want to still exist next year
• A hackathon, thirty-six hours, four people
• Teaching a class of thirty
• A test fixture for CI
• A prototype that might become production
• Memory for an AI agent

Or skip the reading and run decide.py, which applies the same reasoning in six questions.

---

A side project you want to still exist next year

The failure mode here is not scale. It is that you stop touching the project for five weeks, come back on a Sunday evening with an hour of enthusiasm, and find the database paused, expired or requiring a billing update before it will answer.

That is the single most important property to select on, and it is the one nobody puts in a comparison table. Some free tiers suspend an idle project and need a click to wake; some delete the instance after a fixed window; some are permanent and just small. Before you look at storage limits, find out which of those three you are signing up for.

The second property is export. A side project's data is usually irreplaceable precisely because it is not important enough to have a backup strategy. If you cannot run something equivalent to pg_dump on demand, you have chosen a place your data lives rather than a place it is stored.

Engine-wise, pick PostgreSQL unless you have a specific reason not to. Not because it is the best database — because it is the one where every future decision stays open. JSONB handles the documents you thought you needed Mongo for, and pg_dump output loads into any Postgres anywhere.

Do this: a PostgreSQL instance on a free tier with no expiry timer, and a pg_dump to your laptop the first week, so you know the export path works before you need it. A free PostgreSQL instance on freebase.cloud has no expiry attached and takes a card-free signup; Aiven's free Postgres plan and MongoDB Atlas M0 are equally reasonable choices with the same property.

A hackathon, thirty-six hours, four people

Different problem entirely. Nothing you build this weekend needs to survive a schema migration, and the cost of a bad database decision is bounded by Sunday afternoon. What matters is the number of minutes between "we need to store this" and "it is stored".

Three things will actually slow you down: a signup flow that wants a credit card while one teammate has left their wallet at the hotel; a schema you have to redesign at 2am because the API you are consuming returns a field you did not plan for; and four people sharing one connection string that somebody rotates.

That argues for a document store or a key-value store rather than a relational schema — not because documents are better, but because ALTER TABLE at 2am is a bad time. It also argues for signing up once and sharing one instance rather than four, so nobody is debugging a laptop-local database at the demo.

If your hack is a leaderboard, a queue, a live counter or anything with a "top ten" in it, Redis will be one line per feature: ZADD, ZREVRANGE, INCR, EXPIRE. If it is "store the things the API gave us and show them", use MongoDB and stop thinking about it.

Do this: one shared instance, created by whoever is least likely to close their laptop. Free MongoDB and free Redis both speak their native wire protocol, so mongosh and redis-cli work immediately. Upstash is an equally fast route to Redis if your stack is serverless.

Teaching a class of thirty

The constraint you are optimising is not technical. It is that thirty people with thirty different laptops, three operating systems and varying levels of comfort with a terminal all need to reach the same starting line in the first ten minutes of the session, or you lose the room.

Every requirement that sounds trivial to you is a failure point at scale: installing a client, setting a PATH, opening a port, entering a credit card. A student who cannot sign up because they do not have a card is not a small problem — it is one you cannot fix from the front of the room.

Give each student their own instance rather than one shared database. Shared databases in classes end the same way every time: somebody runs DROP TABLE and forty minutes of the lesson evaporate. Individual instances also mean an exercise can say "now break it" and mean it.

For the engine, PostgreSQL or SQLite, depending on what you are teaching. SQLite for pure SQL syntax — it is what most textbooks use, the dialect is small and the error messages are readable. Postgres if the syllabus includes anything about concurrency, roles, transactions or realistic types.

Do this: hand out a signup link, not a connection string. Card-free registration is the requirement that matters most. Free SQLite and free PostgreSQL instances need no card and no local install; a browser and thirty seconds gets a student to their first SELECT.

A test fixture for CI

Here is the contrarian answer: you probably do not want a hosted database at all.

CI wants isolation and determinism. A shared hosted instance gives you neither — parallel jobs collide on table names, a flaky test leaves rows behind that break the next run, and a rate limit turns into a red build that has nothing to do with your code. A container inside the CI job is almost always the better tool. services: postgres:16 in GitHub Actions costs nothing and starts clean every time.

Where a hosted instance genuinely earns its place is the narrow band of tests a container cannot run: verifying that your application works against a remote database with real network latency, that TLS negotiation succeeds, that your connection pool survives a dropped connection, or that the managed engine's version actually matches the one you develop against.

If you do use a hosted instance in CI, isolate per run with a schema rather than a database:

CREATE SCHEMA ci_${GITHUB_RUN_ID};
SET search_path TO ci_${GITHUB_RUN_ID};
-- ... migrations, tests ...
DROP SCHEMA ci_${GITHUB_RUN_ID} CASCADE;

Cheap, parallel-safe, and the teardown is one statement. examples/ci_fixture.sh is a working version of exactly this, including the trap that drops the schema when the tests fail.

Do this: containers for the unit tests, one hosted instance for the handful of integration tests that need a real network. A hosted Postgres endpoint reached over the ordinary libpq protocol is enough for the second category.

A prototype that might become production

The trap in this scenario is not choosing wrong. It is choosing something you cannot leave.

Ask three questions of any free tier before you write code against it. Can you export everything yourself, without filing a support ticket? Is the engine the real thing, or a compatible reimplementation whose differences you will discover under load? And if the free tier disappeared tomorrow — as free tiers demonstrably do — could you point your existing driver at another host and keep going?

That last question is why the wire protocol matters more than the feature list. A database you reach with psql and a standard connection string can be replaced by any other Postgres in an afternoon. A database you reach through a vendor SDK cannot, and the effort to leave grows with every feature you adopt.

The recent history here is not theoretical. Heroku's free Postgres tier ended in November 2022. ElephantSQL wound down entirely. PlanetScale removed its hobby plan and now documents plainly that there is no free plan. Render's free Postgres instances expire after 30 days, down from 90. None of those teams announced it a year in advance.

So: use the free tier, but keep the escape hatch open. Standard engine, standard protocol, a dump you have actually tested restoring.

Do this: PostgreSQL, over the real wire protocol, with a scripted export in your repository from day one. freebase.cloud's Postgres engine page covers an instance that exposes pg_dump-style helpers over MCP alongside the 5432 endpoint — but the point is the property, not the provider. Any host that gives you libpq and a dump satisfies it.

Memory for an AI agent

An agent that "remembers" via a growing context window does not remember. It re-reads. That works until the transcript exceeds what you can afford to send, at which point the earliest facts fall out of the window and the agent starts contradicting itself.

Real memory means a database the model can query, which changes what you are selecting for. You want an engine whose schema the model can inspect and describe, a query language it has seen a great deal of during training, and a connection method that does not require you to write and host a tool server yourself.

That last point is what MCP is for. An MCP endpoint turns a database into tools the model can call directly — no wrapper service, no function-calling boilerplate. freebase.cloud exposes four tools per connection, prefixed with whatever you named it. Using scratch:

Tool	What the model does with it
scratch_query	Reads. SQL, or the engine's own language.
scratch_store	Writes a new fact or updates an existing one.
scratch_list_tables	Discovers the schema instead of being told it every turn.
scratch_annotate_table	Records what a table means, once, so later sessions do not re-derive it.

The fourth is the one people skip and then wonder why the generated SQL is wrong. A model reading ts, k, v, src will guess; a model reading "one row per remembered fact, src is the conversation id it came from" will not.

Engine choice: PostgreSQL, because models write correct PostgreSQL more reliably than they write correct anything-else, and because EXPLAIN on a bad generated query tells you something. MongoDB is a reasonable second if the facts genuinely have no common shape.

Do this: one table, described with annotate_table, queried over MCP. examples/agent_recall.py is a complete working loop — store, list, annotate, retrieve — in about a hundred lines of standard-library Python. Setup for Claude and PostgreSQL is a URL paste, nothing more.

---

Running the questionnaire

python3 decide.py                    # six prompts, plain text answer
python3 decide.py --questions        # the question keys, for scripting
python3 decide.py --json --answers use=prototype,shape=relational,idle=yes

It prints a recommendation, two runners-up, the reasoning that produced them, and a "watch out" sentence for each engine. Partial answers are fine — it will use what it has and say less.

Nothing is phoned home; the whole thing is one file with no imports outside the standard library.

Connecting, once you have picked

Create an account, start a session, choose the engine, and name the connection. For PostgreSQL, Redis and MongoDB you get a native endpoint and your existing driver connects with no changes. For the rest, and for AI clients, take an MCP token from Settings → MCP → New Token.

claude mcp add --transport http scratch https://freebase.cloud/api/mcp/YOUR_TOKEN

Claude Desktop and the Claude web app take the same URL through Settings → Connectors → Add custom connector — the desktop config file does not support remote HTTP servers, so the UI is the path. Cursor and Zed accept a bare url; VS Code needs "type": "http" inside a servers object; Cline wants streamableHttp and Roo Code wants streamable-http, which is exactly the kind of detail that costs an hour if you guess.

What this guide will not tell you

Which provider has the largest free storage allowance. Those numbers change without notice and any figure written here would be wrong within months — check the vendor's own page on the day you sign up.

It also will not tell you that free tiers are equivalent to paid infrastructure. They are not. They are for development, prototyping and small production workloads — the ones linked throughout this guide included — and the honest version of every recommendation above includes "and if this succeeds, you will pay someone".

See also

• examples/ — the CI schema-per-run script and the agent memory loop, both runnable.
• freebase.cloud — free instances across fifteen engines, no card.
• Model Context Protocol — the spec behind the tool table above. Streamable HTTP is the current transport; the older HTTP+SSE transport is deprecated.

---

freebase.cloud is an independent service and is not affiliated with Aiven, MongoDB, Inc., Upstash, Salesforce (Heroku), PlanetScale, Render, ElephantSQL, GitHub or Anthropic.