Moogo launches hosted SQLite database giving each project its own file

Moogo has launched a hosted database service that breaks from the dominant DBaaS recipe of putting a polished API in front of Postgres. According to a launch post by the company on dev.to, every Moogo project gets its own SQLite file, reached entirely over HTTP with an API key — no drivers, no connection strings, no pool to babysit.

One file per project

The post lays out three problems the design targets. Serverless functions have no long-lived process, so developers end up building connection pools or running a pooler such as PgBouncer in front of the database. Shared multi-tenant databases depend on row-level security policies that fail when a policy is written with a missing filter — a pattern the company describes as the most common multi-tenant breach in the ecosystem, though it offers no data to support that claim. And a large share of applications are just a few tables and a few megabytes, needing reliability and speed more than Postgres's feature list.

Moogo's answer is structural isolation: each query runs against a separate file, opened by a separate file handle, and physically cannot reach another project's data. There is no tenant_id to filter on because there is no shared table. Writes also skip row-level security evaluation and cross-tenant index contention, which the company says is where the speed comes from.

Prepared statements only

The API accepts parameterised queries only: a statement string plus an array of bound arguments. Values never travel inside the SQL text, so a value can never become syntax — the post claims this makes SQL injection structurally impossible on this path rather than merely discouraged.

Every statement is tokenised and inspected before execution, and several operations are rejected outright: ATTACH, readfile, writefile, load_extension, stacked statements and triggers. Triggers are declined on purpose, because a trigger body contains semicolons and reliably detecting stacked statements would require a real parser; the company suggests writing invariants in application code instead. ATTACH is refused because it would turn the write endpoint into a file reader for the entire host.

Keys, budgets and ceilings

Integration consists of a moogo_-prefixed key and a URL. Projects never pause — there is no idle timeout, and therefore no cold start to design around or slow first request to explain away. Keys are displayed once, at creation and at rotation; the server stores only a SHA-256 hash plus an eight-character prefix. The consequence, as the post frames it, is that a leaked database dump would not hand an attacker a list of working keys, and one exposed key does not reveal the others.

Every request has a time budget and every project a size ceiling, and both values are returned in the response. Enforcement happens before work is committed: a write that would cross the size limit is refused outright rather than truncated.

What you give up

The post is unusually blunt about limitations. There is no PostGIS-class spatial support, since SQLite's R-Tree is not PostGIS. There are no cross-region replicas, because each project lives as a single file on a single host. Concurrent analytical scans are out, as SQLite is a single-writer engine. Databases are capped at 100 MB, and the cap is enforced. There is one role per project key, so no GRANT or REVOKE. Self-hosting is planned but absent from this version. On the current tier, accounts get two projects, 100 MB per database and 256 MB of storage per project, and there is no billing yet — every account sits on the same plan.

Why it matters

Nearly every managed database launched in recent years has been Postgres underneath, so the operational conversation has centred on pooling and row-level-security correctness. Moogo bets the other way: for serverless functions, small SaaS products, internal tools and AI agents that need durable memory, an embedded engine with file-per-project isolation and an HTTP interface removes whole categories of work — connection management, driver versioning, policy-based multi-tenancy — by construction rather than by configuration. The claims are the vendor's own, from a launch post rather than independent testing, and the 100 MB ceiling and single-writer model are hard constraints. But as a position in the DBaaS market it is a genuinely different bet: move isolation from policy correctness to physical separation, and the most common multi-tenant failure mode stops being a configuration mistake waiting to happen.