10 Ways Layerbase Is Changing Managed Databases
Short version: Layerbase bills a flat monthly price with no usage meters anywhere, runs 21 engines with 18 of them self-serve in the cloud on one account, branches 16 of those engines rather than just Postgres, sleeps idle databases and wakes them over the standard wire protocol, ships TLS and IP allowlists on the free plan, and refuses any delete it cannot back up first. The ten items below are those decisions with the specifics attached.
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. 18 engines behind one signup
Layerbase runs 21 database engines, 18 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, TigerBeetle, 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 16 cloud engines: PostgreSQL, MySQL, MariaDB, Redis, Valkey, FerretDB, libSQL, SQLite, DuckDB, TypeDB, ClickHouse, Meilisearch, Qdrant, QuestDB, InfluxDB, and Weaviate. 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 the Layerbase CLI (formerly 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.
FAQ
How many engines can I actually create on Layerbase Cloud?
- The full suite is 21, and the gap is MongoDB, CockroachDB, and SurrealDB, which licensing keeps uncreatable in a hosted product. Those three run locally through the Layerbase CLI and on Layerbase Desktop. For document workloads in the cloud the answer is FerretDB, which speaks the MongoDB wire protocol.
Is there really no usage metering on paid plans?
None. No compute-hours, no per-command charges, no read/write units, no egress line. The only way your bill changes is if you change something: move up a plan, or add a $10/month block. A month of heavy ingest and a month where nothing connects produce the same invoice.
Which engines support branching?
16 of the cloud engines: PostgreSQL, MySQL, MariaDB, Redis, Valkey, FerretDB, libSQL, SQLite, DuckDB, TypeDB, ClickHouse, Meilisearch, Qdrant, QuestDB, InfluxDB, and Weaviate. Free gets 1 branch per database and Pro gets 10. MongoDB workloads branch through FerretDB.
Do I need a special driver for scale-to-zero?
No. Waking a sleeping database is just reconnecting with the client you already use, over the normal wire protocol. Serverless Postgres elsewhere often means adopting an HTTP driver; here your pg client sees a 1 to 5 second delay on the first connection and nothing else changes.
What happens to my data if I delete a database by mistake?
The delete path takes a backup before it acts and refuses to proceed if it cannot secure one. The most recent backup is never pruned. That is enforced in the deletion code rather than promised in a support doc, and it covers free databases.
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.
Keep reading
- MariaDB 13.0 and 12.3 LTS on Layerbase: which line to pickMariaDB 13.0 and 12.3 are now offered on Layerbase alongside 10.11, 11.4 and 11.8, and the older lines have been refreshed to their current patches. Here is what actually shipped in 13.0, what 12.3 changed, why one of them is the LTS and the other is not, and what happens to databases already on 11.8 (nothing).
- Sleep vs Pause vs Archive: Why Free Databases Fail DifferentlyA sleeping database wakes on your next query, a paused project waits for a human to click Resume, and an archived one waits for you to ask for it back. The difference decides whether an idle week costs you three seconds or an afternoon of debugging the wrong layer.
- Point-in-time restore is generally available, including FerretDBContinuous WAL archiving and restore-to-any-timestamp are now switchable from the Backups tab of any always-on PostgreSQL or FerretDB database on the Pro plan. A restore builds a new database and never touches the source. FerretDB gets it because its documents live in Postgres, and we proved that over the MongoDB wire before writing this.
- Point-in-time restore for Postgres: we lose seconds now, not an hourHourly dumps mean a bad DELETE at :59 costs you most of an hour, unrecoverably. We built continuous WAL archiving and restore-to-any-timestamp for always-on Postgres on Layerbase, then proved it with an executed drill: the row written two seconds before the target came back, the row written four seconds after it did not.