LayerbaseLayerbase

IBM Cloudant deprecations in 2025 and 2026: database caps, QuickJS, and removed features

CouchDBCloudantNoSQLDatabases

IBM Cloudant has been the default managed Apache CouchDB for over a decade. Over the past 18 months it has quietly racked up a list of caps, deprecations, and feature removals that, taken together, change the calculus for anyone running a small CouchDB app on it. The Lite plan now caps at 20 databases. The Standard plan caps at 200. SpiderMonkey is being removed on October 6, 2026. The _show, _list, _update, and _rewrite design-doc handlers are deprecated and unsupported. Replicator proxy fields are gone.

This post is the dated, sourced rundown of what changed, who it affects, and what to do if any of it breaks your app. Everything below cites IBM's own Service Changes and Deprecations page and the QuickJS migration FAQ.

If you just want the punchline: Layerbase Cloud hosts Apache CouchDB with a real free tier, no database-count caps on the dev tier beyond the storage envelope, and a one-line replication migration off Cloudant. Skip to the migration section if that's what you're here for.

Contents

The new database-count caps (March 3, 2025)

Effective March 3, 2025, any newly created Cloudant instance has a hard limit on the number of databases it can hold:

  • Lite plan: 20 databases max.
  • Standard plan: 200 databases max.

Once the cap is hit, the next PUT /{db} returns HTTP 403. You can check the current count via /_api/v2/user/current/databases and the cap via /_api/v2/user/capacity/databases. Instances created before March 3, 2025 are exempt and stay uncapped.

This one is the most disruptive of the recent changes for small-team workloads, because CouchDB encourages a "database per tenant" or "database per user" pattern for offline-first apps. A multi-user app following that pattern hits the Lite cap at 20 users. Even Standard plans (which currently start at around $77 per month) cap at 200, which is fine for a backend but tight for a per-tenant model with any real growth.

If you need more, IBM's docs suggest sharding across multiple instances or opening a support case for a case-by-case exception. That works, but it shifts an operational problem onto you that didn't exist before March 2025.

Layerbase Cloud doesn't impose a per-instance database count cap. The free dev tier limits total storage, not the number of databases inside the instance. If you're running a per-tenant CouchDB app and hit Cloudant's 20-db Lite wall, that constraint goes away on Layerbase.

SpiderMonkey is being removed on October 6, 2026

Cloudant is replacing the SpiderMonkey JavaScript engine with QuickJS across all instances. The reasons IBM gives are ES2023 feature support and faster index building, both of which are real wins.

The catch: some JavaScript features that worked in SpiderMonkey don't work the same way in QuickJS. IBM says they have analysed customer design documents and that fewer than 1% of customers will need to change anything, but the failure modes are exactly the kind that bite hard if they bite you:

  1. Exceptions in design-doc functions. Documents fail to index, and queries that rely on JavaScript views or filters return errors.
  2. Silent result drift. Functions like parseInt behave slightly differently. Indexes still build, queries still return, but the values are wrong.

The remaining SpiderMonkey instances will be migrated to QuickJS by October 6, 2026. After that, all JavaScript in Cloudant runs on QuickJS, full stop. Indexes do not need to be rebuilt during migration, and there is no downtime.

You can check whether your instance is already on QuickJS:

bash
curl -X GET https://$ACCOUNT.cloudant.com/

If quickjs is in the features array, you are already migrated and nothing else is required. If it is not, you have until October 6, 2026 to audit your design documents.

Worth noting: Apache CouchDB itself has already started adopting QuickJS upstream. CouchDB 3.4 added QuickJS as an opt-in JavaScript engine (alongside the SpiderMonkey default), and the planned 3.6.0 release flips QuickJS to be the default while keeping SpiderMonkey selectable. So if you run vanilla CouchDB (self-hosted, on SpinDB, on Layerbase Cloud, or anywhere else that ships the Apache binary), you can audit your design docs against QuickJS on your own schedule rather than against Cloudant's October 6, 2026 cutover, and you can fall back to SpiderMonkey per-instance if you find a regression.

_show, _list, _update, _rewrite design-doc handlers deprecated

If your CouchApp uses any of these:

  • _show functions, which let you transform a single document's response format
  • _list functions, the equivalent for MapReduce view output
  • _rewrite functions, used for routing inside a CouchApp
  • _update functions, which run server-side business logic on writes (timestamps, validation, etc.)

They are deprecated. Cloudant has not given a removal date, but here is what is already true:

  1. They are not documented anymore.
  2. They are not supported by Cloudant Support.
  3. They are not in any Cloudant SDK.
  4. Apache CouchDB itself plans to remove them in 4.0.

In practice, this means anything built in the CouchApp era (single-page apps served directly out of CouchDB with _rewrite, custom JSON formats via _show, server-side validation via _update) is on borrowed time. The pattern still works for now, but a new feature request to extend a CouchApp is the moment to consider porting that logic to a regular application server.

If you self-host on Apache CouchDB 3.x or on a managed Apache CouchDB build (including Layerbase Cloud), these handlers still work and follow Apache's deprecation timeline rather than Cloudant's. Apache 4.0 is the cutoff there.

Replicator endpoint proxy support removed

This one is already done. The proxy, source_proxy, and target_proxy fields on the Cloudant replicator are removed. Any replication job that includes one of those fields fails with an error.

If your replication topology depends on routing through a forward proxy, you need to either:

  • Remove the proxy field and replicate directly (if network policy allows).
  • Replicate through an intermediate CouchDB you control (self-hosted, Layerbase Cloud, SpinDB) that does the proxy hop itself.

Replication itself is unchanged, only the proxy fields are gone.

Temporary lockout for legacy (non-IAM) credentials

Cloudant is rolling out temporary account lockout after multiple failed login attempts on legacy (non-IAM) credentials. Unlocking is either time-based or password-reset-based, with a roughly 5-minute propagation window after a reset.

If you authenticate with IAM (the modern, recommended path), this does not apply to you. If you still use legacy username and password credentials (common in older apps, scripts, and CouchApps), expect lockouts under load if anything is hammering the auth endpoint with bad credentials. Rotate to IAM if you can, and add retry-with-backoff if you cannot.

Pricing as of 2026

For comparison, here is what Cloudant currently charges:

PlanCostThroughputStorageDatabase cap
LiteFree20 reads/s, 10 writes/s, 5 global queries/s1 GB20 databases
StandardVariable - throughput blocks (hourly proration)100 reads/s, 50 writes/s, 5 global queries/s baseline (adjustable)20 GB included; additional storage billed per GB-month (variable rate)200 databases
EnterpriseCustomDedicated single-tenantNegotiatedNegotiated

A few things stand out:

  • The Lite-to-Standard jump is large. Lite is free; Standard is variable - you provision capacity in throughput blocks (separate lookups, writes, and global queries) with hourly pro-ration, and you pay per GB-month for storage above the included 20 GB. A minimal Standard configuration runs in the high-double-digits per month, but the bill scales with whatever throughput and storage you allocate. There is no in-between for a small but live workload, and the 20-database cap on Lite makes it a true toy tier.
  • The Standard plan meters reads, writes, and global queries separately, all in capacity units rather than per-request, which makes cost forecasting hard for spiky workloads.
  • The 1 MB max document size is a hard cap, which can be a surprise during attachment-heavy work.

Layerbase Cloud offers a free CouchDB tier with no credit card, no database count cap inside the storage envelope, and add-on pricing only for the things you choose to turn on (keep-warm, larger storage, scheduled backups, region pinning). The engine itself stays free at the dev tier.

Who gets squeezed

Putting the changes together, the people most affected are:

  1. Per-tenant CouchDB apps using database-per-user. The 20-db Lite cap blocks new free instances at 20 tenants, and Standard tops out at 200. Multi-tenant SaaS apps built on the canonical CouchDB pattern hit this fast.
  2. Hobby projects on Lite. 1 GB and 20 databases on Lite are now real ceilings, and the jump to ~$77/mo on Standard is steep for a side project.
  3. CouchApp users. The _show/_list/_update/_rewrite deprecations target the original "database as application server" pattern. Anyone still running a CouchApp is on a feature-frozen path.
  4. Apps with non-trivial JavaScript design docs. Fewer than 1% of customers, by IBM's count, but if you are one of them, the October 6, 2026 cutover is a real deadline.
  5. Replication topologies that depended on proxy fields. Already broken.

If you fit any of these categories, the rest of this post is about where to go.

How to migrate off Cloudant

CouchDB's killer feature is that its replication protocol is universal. Any CouchDB instance can replicate to any other CouchDB instance, regardless of who hosts either side. Migrating off Cloudant is mostly a POST to /_replicator, run once per database. There is no "export" or "dump" step, and zero-downtime migrations are a flag away.

Here is the short version. The full step-by-step is in Migrating from IBM Cloudant to Layerbase Cloud, with rollback and verification steps.

  1. Create a Layerbase Cloud CouchDB instance. Click here, pick CouchDB, and grab the admin URL.
  2. Trigger a one-shot replication for each Cloudant database:
bash
curl -X POST https://admin:password@your-host.cloud.layerbase.dev/_replicator \
  -H "Content-Type: application/json" \
  -d '{
    "source": "https://APIKEY:PASSWORD@your-cloudant.cloudantnosqldb.appdomain.cloud/yourdb",
    "target": "yourdb",
    "create_target": true,
    "continuous": false
  }'
  1. Verify document counts match, rebuild any Cloudant Search (Lucene) indexes as Mango indexes, and swap your connection string at deploy time.

For multi-database migrations, the couchreplicate CLI parallelises the replication jobs and bounds concurrency so you do not overload either side.

Where to go from here

If your only objection to leaving Cloudant has been the lack of a serious alternative, that objection has expired. Migration is one HTTP call per database, the replication protocol works in both directions (so rollback is just as easy as cutover), and you stop renting database-count quota from IBM.

Get a free CouchDB on Layerbase Cloud and replicate your first database in five minutes.

Something not working?