Why Moogo?

moogo.dev — Sat, 10 Oct 2026 03:03:51 +0000

Most hosted databases are Postgres with a nice wrapper. Moogo is not. It is built
around a different bet: for a large class of applications, one SQLite file per
project is a better fit than a shared Postgres cluster, and the ergonomics of
the API matter more than the feature list of the engine.

This page explains the reasoning, including the trade-offs that come with it.

The problem Moogo is solving

If you are building a serverless function, a small SaaS, an internal tool, or an
AI agent that needs to remember things, you run into the same three problems.

1. Connection management is your problem. A serverless function has no
long-lived process. Every cold start means a new connection. You end up writing a
connection pool, or putting PgBouncer in front, or paying for a driver that
manages sockets for you.

2. A shared database means shared risk. In a multi-tenant Postgres, isolation
is a set of row-level security policies. They are well understood and they work —
until a policy is written with one too few WHERE clauses, and one tenant reads
another tenant's rows. This is not a hypothetical; it is the most common
multi-tenant data breach in the ecosystem.

3. You do not need Postgres. A huge fraction of applications are a few
tables, a handful of queries, and a few megabytes of data. What they need is
reliability, speed, and not having to think about the database at all. SQLite has
been the most-used embedded database in the world for over a decade, and it is
fast enough for essentially all of this.

Moogo takes that bet: give each project a whole SQLite file, and expose it over
HTTP, and most of the operational work disappears.

The decisions that follow from that

One file per project, not a shared cluster

This is the decision everything else follows from.

Isolation becomes structural instead of policy-based. There is no tenant_id to
filter on because there is no shared table. A query physically cannot reach
another project's data, because it is running against a different file opened by
a different file handle.

It is also why Moogo is fast. A write goes straight into the project's own file
with no row-level security evaluation, no cross-tenant index contention, and no
neighbour making your INSERT slow.

Prepared statements only, enforced

Values never travel inside your SQL text. They are bound parameters:

{ "query": "SELECT id FROM users WHERE email = ?", "args": ["ketut@example.com"] }

The engine only ever sees a parameterised statement. This means a value can never
become syntax, which is the whole class of SQL injection bugs — not "mostly
prevented", but structurally impossible on this path.

Every statement is also tokenized and inspected before it runs. ATTACH,
readfile, writefile, load_extension, stacked statements, and triggers are
rejected outright. See Security for the full list and why each
one is refused.

No drivers, no cold starts

A moogo_... key and a URL are the entire integration. There is no driver to
install, no version to keep in sync with your runtime, and no connection to leak
when your function is frozen and thawed.

The project never pauses either. There is no idle timeout, so there is no cold
start to design around and no "first request is slow" to apologise for.

Keys you can throw away

The project key is shown once, when the project is created and when it is
rotated. What is stored is a SHA-256 hash plus an eight-character prefix.

The consequence is worth stating plainly: a leaked database dump does not hand an
attacker a list of working keys. A key that appears in a log, a screenshot, or a
public repository is a key you need to rotate, but it is not a key that reveals
the others.

Limits you can see

Every request has a time budget and every project has a size ceiling. Both come
back in the response, and both are enforced before the work is committed rather
than discovered afterwards. A write that would cross the size limit is refused; it
is not silently truncated.

The trade-offs, stated honestly

Moogo is not the right tool for everything, and pretending otherwise would waste
your time.

You probably want something else if	Why
You need `PostGIS` or spatial queries	SQLite has `R-Tree`, but it is not PostGIS
You need cross-region replicas	One project is one file on one host
You need concurrent analytical scans	SQLite is a single-writer engine
You need a database larger than 100 MB	That is the ceiling, and it is enforced
You need row-level security across tenants	You do not need it; you get file isolation instead
You need `GRANT` / `REVOKE` and multiple roles	Moogo has one role per project key

On the free tier you also get 2 projects per account, 100 MB per database,
and 256 MB of storage per project. There is no billing in the current version, so
every account is on the same plan. If you need more than that, the constraint is
a real one and you should know about it before you build.

What is deliberately missing

Some things are absent on purpose, not by accident:

No triggers. A trigger body contains semicolons, so detecting stacked statements correctly needs a real parser. Rather than ship a check that fails open on input SQLite accepts, triggers are declined. Write your invariants in your application.
No ATTACH. It would turn the write endpoint into a file reader for the whole host.
No idle pausing. It is a feature you would have to design around, and Moogo is always on.
No self-hosting yet. It is planned, and it is not in this version.

Try moogo at https://moogo.dev

What is Moogo?

moogo.dev — Fri, 09 Oct 2026 06:26:02 +0000

Moogo is a hosted backend that gives every project its own SQLite database and
its own object storage, reachable over plain HTTP. There is no connection
string, no driver, and no database client to install.

You create a project, and Moogo hands you three values:

MOOGO_PROJECT_URL=https://api.moogo.dev/p/8f3c1a20-5b7e-4a91-9d3c-2f6b81e4a7d0
MOOGO_PROJECT_ID=8f3c1a20-5b7e-4a91-9d3c-2f6b81e4a7d0
MOOGO_SECRET_KEY=moogo_...

Put those in your application's environment and it can read and write data:

curl $MOOGO_PROJECT_URL/query \
  -H "Authorization: Bearer $MOOGO_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"SELECT id, email FROM users WHERE plan = ?","args":["pro"]}'

That is the whole integration. No SDK, no ORM, no connection pool to manage.

The two planes

Everything about Moogo follows from one architectural decision: the service runs
in two tiers, and they never mix.

Plane	Runs on	Holds	Touches your data?
Control plane	PostgreSQL	Accounts, projects, key hashes, quotas, the bucket catalog, activity logs	No
Data plane	SQLite, one `.db` file per project	Your tables and your rows	Yes

The control plane knows that a project exists. The data plane holds what is in it.
A query never crosses between them, and a bug in the control plane cannot reach
your rows.

Why this matters to you

Because the data plane is one physical file per project, isolation is not a
policy that can be misconfigured. Project A and project B are two different files
on disk. There is no shared connection, no shared buffer pool, and no query that
can be written to cross from one to the other. A project belonging to another
account answers 404, not 403, so an id cannot even be probed for existence.

What you get

A real SQLite database. Full SQLite, the engine you already know, with WAL journaling and foreign keys enabled on every connection.
Object storage per project. Up to 256 MB of files, organized into buckets, with public URLs you can put in an <img> tag.
A dashboard. Browse your tables as a spreadsheet, run SQL in a console, and watch the activity log. It needs no secret key from you.
Honest limits. 100 MB per database, 15 seconds per statement, 1 MB per request body. Every one of them is reported in the response, so you find out from the API rather than from a hung tab.

What Moogo is not

It is worth being direct about the edges.

It is not Postgres. If you need PostGIS, logical replication, or concurrent analytical workloads, Moogo is the wrong tool.
It is not a global replica network. One project is one file on one host. There is no read replica in another region.
It does not pause. A project does not go to sleep after inactivity, so there is no cold start and no "first request after idle" latency. It also never pauses on its own — if you want to stop paying resources for an unused project, you pause it deliberately.

Visit https://moogo.dev

DEV Community: moogo.dev