10 Ways Layerbase Is Changing Managed Databases

Managed databases converged on a formula over the last decade: one engine per vendor, usage-metered billing, security features behind the enterprise tier, and a free tier that exists until the finance team notices it. We built Layerbase against that formula on purpose. Here are the ten decisions that matter most, with the concrete details behind each one.

1. Flat pricing, no meters, on any plan

There is not a single usage meter anywhere in Layerbase pricing. No compute-hours, no per-command charges, no read/write units, no egress line item. Free is $0, Solo is $5/month, Pro is $15/month for up to 10 databases, and capacity beyond the included pool comes in $10/month blocks (+1 GB RAM, +1 vCPU, +25 GB storage). Your bill next month is your bill this month unless you changed something yourself. That is the whole billing model.

2. 20+ engines behind one signup

Layerbase runs 21 database engines, 17 of them self-serve in the cloud today, plus MongoDB compatibility through FerretDB. Postgres, MySQL, MariaDB, Redis, Valkey, SQLite, libSQL, DuckDB, ClickHouse, QuestDB, InfluxDB, Qdrant, Weaviate, Meilisearch, CouchDB, FerretDB, TypeDB: one account, one dashboard, one bill. The alternative is a vendor per engine, which is how the multi-database tax happens.

3. Engines nobody else will host for you

As of July 2026, QuestDB Cloud is discontinued (only the sales-gated Enterprise/BYOC path remains), and no self-serve managed Apache CouchDB exists anywhere (IBM Cloudant is a fork, not CouchDB). Layerbase hosts both, self-serve, today. FerretDB's own cloud is waitlist-gated and its free tier lacks TLS; ours has neither problem. If you run one of these engines, we are not a cheaper alternative to your managed option. We are the managed option.

4. Branching that is not a Postgres-only trick

Database branching, a writable copy of your database in seconds, works on 9 cloud engines: PostgreSQL, MySQL, MariaDB, Redis, Valkey, FerretDB, libSQL, SQLite, and DuckDB. MongoDB workloads branch via FerretDB. Every other provider that offers branching offers it for exactly one engine. Free includes 1 branch per database; Pro includes 10.

5. Scale-to-zero without a proprietary driver

Idle databases sleep, and waking one is just reconnecting: your existing client retries, the database is back in roughly 1 to 5 seconds, and the client sees a delay rather than an error. This works on every engine family, over the standard wire protocol. Postgres serverless elsewhere usually means an HTTP driver you have to adopt; here it means pooled TCP connections and the same pg client you already use. There is nothing to migrate onto and therefore nothing to migrate off.

6. Security is not an upsell

TLS on every engine and every tier, per-database IP allowlists, and generated credentials, all included on the free plan. The industry habit of parking basic transport security and network controls behind an enterprise SKU never made sense to us: the databases most likely to be left exposed are exactly the free-tier experiments.

7. A never-lose-data guarantee that is code, not copy

Every destructive path in the platform takes a backup before it acts, and deletion is refused outright if a final backup cannot be secured first. The most recent backup of a database is never pruned. This is enforced in the deletion code itself, not promised in a support doc, and it applies to free databases too.

8. Drop-in compatible with the code you already wrote

Every Valkey database includes a built-in HTTP queue that works with the open-source @upstash/qstash client: publish, batch, delay, retries, and dead-letter inspection work, with signatures that Receiver.verify() accepts verbatim. Redis and Valkey expose a REST API that works with the open-source @upstash/redis client from edge runtimes. MySQL and MariaDB answer the open-source @planetscale/database driver over HTTP. Vercel KV data imports directly. The pattern: keep your client code, change an environment variable.

9. Leaving is easy, which is why arriving is

/migrate does guided, read-once imports from Neon, Supabase, Render, Railway, PlanetScale, Upstash, Vercel KV, Algolia (into Meilisearch), and Turso. Supabase auth users import with their bcrypt hashes intact, so nobody has to reset a password. And the exits stay open: everything speaks its standard protocol, standard dump tooling works, and the same engines run on your own hardware with spindb, our source-available local CLI, so local dev and self-hosting are always on the table. Lock-in is a pricing strategy. We would rather be the thing you stay on than the thing you cannot leave.

10. Support is a person, within a business day

Support requests get a reply from a human within one business day. Not a chatbot, not a community forum with a "premium support" upsell hovering over it. On a database product, "a person who can look at your actual instance" is the feature; everything else is deflection.

The through-line

Each of these is a small decision, but they point the same direction: the database should be the boring, predictable part of your stack. Flat price, standard protocols, data that cannot be lost by accident, and an exit door that works. If that sounds like what you wanted managed databases to be all along, create one free. Two databases, 5 GB, eight engines, no card.