IBM Cloudant vs Layerbase Cloud: managed CouchDB compared in 2026

If you are running CouchDB and weighing IBM Cloudant against Layerbase Cloud, the short version: Cloudant is the long-running incumbent with the heavier enterprise feature set, and Layerbase Cloud is the modern managed Apache CouchDB at a flat $15/mo with no capacity units to reserve. The interesting comparison is which one fits your specific app, not which one is "better."

This post is the side-by-side. Everything below cites either Cloudant's pricing and deprecations docs or the public Layerbase Cloud pricing page. If you are looking for the broader survey of options, see Cloudant alternatives in 2026. If you are looking for the migration steps, see Migrating from IBM Cloudant to Apache CouchDB.

Contents

• At a glance
• Free tier
• Pricing model
• Database-count caps
• The CouchDB engine
• JavaScript engine and design documents
• Region coverage and egress
• Backups and replication
• Console and developer ergonomics
• Search and full-text
• SLA, support, and lifecycle
• Which one to pick

At a glance

Free tier

This is the line item that has shifted the most in the last 18 months.

Cloudant Lite is free, but the caps tightened in March 2025. The current envelope:

• 1 GB storage
• 20 reads per second, 10 writes per second, 5 global queries per second
• 20 databases maximum for instances created after March 3, 2025
• 1 MB max document size

The 20-database cap is the part that bites hardest. CouchDB encourages database-per-tenant and database-per-user patterns for offline-first sync, and 20 tenants is not enough headroom to actually ship a small SaaS on Lite.

Layerbase Cloud does not have a free CouchDB. Worth saying plainly, because it is the one line where Cloudant wins outright on paper. Layerbase's free tier is real (2 databases, 5 GB, no card) but its engine list is PostgreSQL, MariaDB, SQLite, DuckDB, libSQL, Redis, Valkey, and TypeDB. CouchDB is not on it, and it is not on the $5/mo Solo plan either. Managed CouchDB starts on Pro at $15/mo, which comes with a 7-day trial.

What you get for that $15 is the whole plan, not a CouchDB SKU: up to 10 databases across every engine Layerbase Cloud runs, 25 GB of storage, a 1.5 GB always-on pool, and 30-day rolling backups. And the constraint is storage rather than database count. Inside your CouchDB instance you create as many CouchDB databases as the storage supports, including the database-per-tenant pattern.

So if you are coming from Lite and bumping into the 20-db wall, the wall goes away, but you are trading a free plan for a $15/mo one. If you are coming from Standard, you are trading ~$76.65/mo and a capacity calculator for $15/mo and neither.

Pricing model

The two pricing models are different enough that direct dollar comparisons mislead.

Cloudant uses a provisioned-capacity model. You reserve reads/s, writes/s, and global queries/s in capacity units, and pay for the highest setting in each hourly window. Storage is separate at roughly $1/GB/mo after the 20 GB included. Standard starts at around $76.65/mo for the minimum capacity, and you scale by clicking up the sliders in the dashboard. Surprise bills happen when traffic spikes push capacity units higher than planned, even briefly.

Layerbase Cloud uses a flat plan price. CouchDB lives on Pro, $15/mo, and that number does not move with your traffic. There is nothing to reserve and nothing metered: no reads/s, no writes/s, no global queries/s, no per-GB storage line. The plan includes the resources (10 databases, 25 GB, a 1.5 GB always-on pool, 30-day rolling backups, region pinning), and if you outgrow them, stackable $10/mo pool blocks add 1 GB of always-on RAM, 1 vCPU, and 25 GB of storage each. That is the entire price list.

In practice:

• For a hobby project or a small B2B SaaS, Cloudant Lite is free and Layerbase is $15/mo. Lite wins on price and loses on the 20-db cap and the throughput throttles; pick whichever of those hurts less.
• For a steady, predictable workload past Lite, it is $15/mo flat against Cloudant Standard's ~$76.65/mo floor, and the gap widens as Cloudant's capacity units climb.
• For very large, predictable enterprise workloads, Cloudant's dedicated Enterprise plan and Cloudant on Transaction Engine offering have specialised pricing that may beat any generic managed CouchDB.

Database-count caps

This deserves its own row because it is the new thing.

Cloudant added hard database-count caps on March 3, 2025:

• Lite: 20 databases per instance
• Standard: 200 databases per instance

The caps apply to instances created on or after that date. Older instances are exempt. The cap is enforced server-side: the 21st (or 201st) PUT /{db} returns HTTP 403. Cloudant's documentation suggests sharding across multiple instances or filing a support case for exceptions.

Layerbase Cloud does not add a database-count cap inside your CouchDB instance. You are bounded by the 25 GB of storage Pro includes, not by a count, so the database-per-tenant pattern keeps working past 20 and past 200. (Pro's own "up to 10 databases" limit counts Layerbase instances, meaning separate managed servers, not the CouchDB databases living inside one of them.) For per-tenant CouchDB architectures, this is the single biggest difference.

The CouchDB engine

Both run real Apache CouchDB 3.x. Cloudant adds extensions on top (Cloudant Search, Cloudant Query enhancements, partitioned databases, specific capacity-management endpoints), and tracks a slightly customised version (e.g., 3.5.0+cloudant).

Layerbase Cloud runs the upstream Apache binary unmodified. That means:

• Your code is portable. The same client library calls work against Layerbase Cloud, the Layerbase CLI locally, a self-hosted Apache CouchDB, and (mostly) Cloudant.
• The release cadence is whatever Apache ships.
• There are no Cloudant-specific quirks to learn, and no Layerbase-specific lock-in features either.

If you specifically rely on Cloudant Search or partitioned databases as Cloudant implements them, the Cloudant side wins on parity. If you want a portable Apache CouchDB and the option to move providers later, Layerbase wins on neutrality.

JavaScript engine and design documents

Cloudant is migrating the JavaScript engine that runs design-document views, filters, and _update handlers from SpiderMonkey to QuickJS. The cutover for the remaining SpiderMonkey instances is October 6, 2026. IBM says less than 1% of customers will need to change their design docs, but the failure modes include silent result drift on functions like parseInt.

Layerbase Cloud follows the Apache CouchDB upstream JS engine choice, which today is SpiderMonkey. If your design docs rely on SpiderMonkey-specific behaviour, they keep working on Layerbase without a 2026 deadline hanging over them.

This is not a "Layerbase is better" point, exactly. QuickJS is a sensible upgrade (faster index builds, ES2023). It is more a "neither side is on auto-pilot, and the deadlines are different." If you have non-trivial JavaScript in your design docs, the Cloudant deadline is real and the Apache-upstream cadence on Layerbase is not.

Region coverage and egress

Cloudant runs in six IBM Cloud regions (Dallas, Washington DC, Frankfurt, London, Sydney, Tokyo at last count). Cross-region replication is supported. If your application runs in a non-IBM cloud (AWS, GCP, Azure, Cloudflare, Vercel), every CouchDB request crosses the open internet and may incur egress on the application side.

Layerbase Cloud is vendor-neutral and reachable from any cloud. Region pinning is included on Pro rather than sold separately, so placing your data near your application is not a line item. For Vercel, Cloudflare Workers, or AWS Lambda users specifically, latency is generally lower from Layerbase than from Cloudant because the network path is shorter.

Backups and replication

Both run the standard CouchDB replicator. Both support continuous and one-shot replication. Both support replication between themselves and anywhere else, in any direction, because the protocol is universal.

Cloudant offers point-in-time backups as a managed feature on paid plans, integrated with IBM Cloud Object Storage. The @cloudant/couchbackup CLI is also free to use against any Cloudant or CouchDB instance. Cloudant removed replicator proxy field support, so jobs with proxy, source_proxy, or target_proxy fail.

Layerbase Cloud includes scheduled daily backups with 30-day rolling retention in the Pro price, with restore-from-snapshot from the dashboard. Replicator proxy fields work because Layerbase ships upstream Apache behaviour.

For the migration use case specifically, both directions work the same way, see Migrating from IBM Cloudant to Apache CouchDB for the step-by-step.

Console and developer ergonomics

Cloudant's console is the open-source Fauxton, wrapped in the IBM Cloud chrome. It has not seen a meaningful UX refresh in years. The IBM Cloud surface around it adds account management, billing, and access control, but the actual database-browsing experience is the same as what ships with Apache CouchDB.

Layerbase Cloud's console is a dashboard layer over Fauxton. You can use Fauxton directly when you want the canonical CouchDB experience, and the Layerbase dashboard for everything else (creating instances, switching engines, viewing logs, managing backups, hibernation toggles, regional placement, generated credentials). The dashboard is also where you create instances of the other engines (PostgreSQL, Redis, ClickHouse, Qdrant and the rest) on the same plan rather than a second subscription, which matters if you are running a multi-engine stack.

If you live in a CouchDB-only world and you already know your way around Fauxton, the console difference is mostly cosmetic. If you wrangle multiple databases for one app, the multi-engine dashboard on Layerbase is more useful day to day.

Search and full-text

Cloudant Search is a Lucene-backed full-text index, exposed through a _search endpoint on design documents. It is Cloudant-only and does not exist in upstream Apache CouchDB. If your app depends on it heavily, that is a lock-in cost.

Layerbase Cloud does not offer a Cloudant Search equivalent inside the CouchDB instance. Instead, the recommended pattern is to stream changes from CouchDB's _changes feed into a dedicated search engine like Meilisearch (also available as a one-click engine on Layerbase Cloud). It is a different shape, and migrating from _search to Meilisearch is real work, but the result is a more composable system where the search engine can be scaled, swapped, or replaced independently of the database.

If full-text search inside design documents is critical and you cannot afford to migrate it, Cloudant wins on this one specific axis.

SLA, support, and lifecycle

Cloudant publishes a 99.99% SLA on the Standard plan. Support tiers go from free community to paid enterprise, with response-time guarantees on the paid tiers. Lifecycle is long: Cloudant has been operating since the early 2010s, and IBM's enterprise customer base means it will keep operating.

Layerbase Cloud publishes a 99.9% SLA on paid plans, which is every plan CouchDB can run on. Support is email-based, with response targets tied to plan. Layerbase is younger than Cloudant; in exchange, it is being actively developed (this comparison post itself is a 2026-05 artifact, the dashboard sees feature releases monthly).

If your procurement process requires a 99.99% SLA, that is a Cloudant point. If you weight "is this product being actively built" higher than "has it been around for a decade," that is a Layerbase point.

Which one to pick

Short version:

• Per-tenant SaaS using database-per-user, hitting Cloudant's 20-database cap: Layerbase Cloud. The cap goes away.
• Hobby project or small B2B side-project that fits inside Lite: stay on Cloudant Lite while it is free, and move when the 20-db cap or the throttles start hurting. Layerbase Cloud is $15/mo flat when you get there.
• Existing CouchApp that uses _show, _list, _update, or _rewrite: Layerbase Cloud or self-host. The handlers still work on Apache CouchDB.
• App stack running on AWS, Vercel, Cloudflare, or any non-IBM cloud: Layerbase Cloud. Shorter network path, no IBM Cloud account required.
• App stack already on IBM Cloud, dependent on Cloudant Search, with predictable enterprise workload: stay on Cloudant. The integration depth and the Lucene search are real value.
• Large, regulated enterprise customer with a 99.99% SLA requirement and existing IBM procurement: stay on Cloudant.

The migration is one-line replication if you change your mind in either direction. Cloudant deprecations in 2025 and 2026 has the full list of recent changes, and the migration guide walks the cutover.

Create a CouchDB on Layerbase Cloud to compare side by side. Pro's 7-day trial is enough to spin up an instance, replicate one of your Cloudant databases into it, and run your real workload against both for a week. That is the actual answer.