Skip to content
LayerbaseLayerbase

Cloudant alternatives: managed CouchDB hosting in 2026

9 min readCouchDBNoSQLDatabases

CouchDB is a fantastic database with a strange hosting story. The protocol is HTTP, the wire format is JSON, the replication model is built in, and the offline-first story still beats nearly everything else. The hosting market for it, on the other hand, is basically one company: IBM Cloudant. That has been true for a decade, and as a result a lot of CouchDB users either run their own instance or pay IBM for a managed one and quietly hope that the dashboard never gets a refresh.

If you've landed here searching for "Cloudant alternative," "managed CouchDB hosting," "Cloudant Lite replacement," "serverless CouchDB," or "Cloudant pricing too expensive," you're not alone, and the situation is finally improving. Here's the actual state of CouchDB hosting in 2026, what works, what it costs, and how Layerbase fits into it.

Contents

Why people leave Cloudant

I won't pile on. Cloudant works, it's been running for over a decade, and IBM hasn't ruined it. But the reasons people search for alternatives are pretty consistent:

The pricing model is opaque. Cloudant charges for "lite," "standard," and "dedicated" with reads, writes, and queries each metered differently, plus a per-GB storage cost, plus a separate cost for the "global" tier. The mental overhead of predicting what a workload will cost is real, and surprise bills happen.

The product is dated. The console hasn't seen a meaningful UX refresh in years. The dashboard's Fauxton instance is the same one CouchDB ships open-source. There's nothing wrong with that exactly, but it doesn't feel like a product anyone is investing in.

It's IBM Cloud only. If your stack is on AWS or Vercel or Cloudflare, your CouchDB is sitting on the other side of an internet egress charge. That's not a problem at low scale and a real one at high scale.

There is no other modern managed CouchDB. That's the practical issue. Even people who'd happily leave Cloudant haven't had anywhere to go, so they stay.

Coming from the Cloudant Lite free tier?

Cloudant Lite has been the de-facto free CouchDB tier for years - the place where hobby projects, prototypes, and small-business apps lived without a credit card on file. Over the past few release cycles IBM has steadily tightened the Lite limits and pushed users toward the paid Standard plan. If you've watched the Lite tier get less generous, or hit one of the throughput caps and noticed there's no "small business" tier between Lite and Standard, you're in the cohort this post is written for.

The short version: Layerbase Cloud's answer to Lite is not another free tier, it is a flat price. Managed CouchDB runs on the Pro plan at $15/mo, and that is the whole bill: no reserved reads/s, no writes/s, no global queries/s, no per-GB storage line. You get a managed HTTPS endpoint, generated admin credentials, scale-to-zero hibernation, 30-day rolling backups, and the standard Apache CouchDB 3.x feature set (MapReduce views, Mango queries, replication, design documents, attachments). The same $15 covers up to 10 databases and 25 GB of storage across all 18 engines Layerbase Cloud runs, so the Postgres or Redis sitting next to your CouchDB is not a second subscription.

Layerbase does have a free tier, and it is worth being precise about it: it covers 2 databases and 5 GB across 8 Standard engines (PostgreSQL, MariaDB, SQLite, DuckDB, libSQL, Redis, Valkey, TypeDB). CouchDB is not one of them, and neither is the $5/mo Solo plan's slightly wider list. If you need managed CouchDB, Pro is the plan.

For a side project, an offline-first mobile sync target, a self-hosted alternative to Pouchdb-Server, or a "managed CouchDB SaaS" you can ship a hobby app on, the honest comparison is $15/mo flat against Cloudant Lite's throttles and 20-database cap, or against Standard's ~$76.65/mo floor. Create one here.

Option 1: Layerbase Cloud

Layerbase Cloud hosts CouchDB as a managed engine on the Pro plan, $15/mo. Sign in, create an instance, and you get an HTTPS endpoint and admin credentials.

bash
curl https://admin:password@<your-host>.cloud.layerbase.dev/
text
{"couchdb":"Welcome","version":"3.4.2","features":["access-ready","partitioned","pluggable-storage-engines","reshard","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

Everything you know about CouchDB still works. Documents are JSON, every operation is HTTP, the replicator works against any other CouchDB instance (including a local one, including a Cloudant one, which makes migration straightforward). MapReduce views, Mango queries, design documents, attachments, all of it.

A few practical notes specific to managed hosting:

Scale-to-zero is on by default. A CouchDB instance hibernates after six idle hours, and CouchDB cold-starts in under a second, so the first request back is barely noticeable. If you have continuous traffic this never matters. If you have spiky traffic and don't want the cold-start hop at all, pin the database always-on: Pro ships a 1.5 GB always-on pool and CouchDB draws 256 MB of it, so pinning is included rather than an extra charge.

Replication works in both directions. You can replicate from a local CouchDB on your laptop to a Layerbase-hosted one, or from Cloudant to Layerbase, or from Layerbase back out to anywhere else. CouchDB's universal replication protocol is part of what makes leaving any host straightforward, and the same protocol gets you in.

If you're coming from Cloudant, the connection-string swap is the only meaningful migration step. CouchDB clients use the same HTTP interface on any host.

Option 2: Run it locally with the Layerbase CLI

For development, local prototyping, or building offline-first apps where the server side runs on your laptop, the Layerbase CLI (formerly SpinDB) is the fastest way to a real CouchDB. No Docker, no IBM Cloud account, no manual binary install. (What is the Layerbase CLI?)

bash
npm i -g layerbase        # npm
pnpm add -g layerbase     # pnpm

Create and start:

bash
lbase create couch1 -e couchdb --start
bash
lbase url couch1
text
http://admin:password@127.0.0.1:5984

That URL is a working CouchDB. You can hit it with curl, point nano at it, or use PouchDB's HTTP adapter for offline-sync development. The version the Layerbase CLI installs is the real Apache CouchDB binary, not a re-implementation.

bash
lbase stop couch1
lbase start couch1
lbase list

A common pattern: develop locally with the Layerbase CLI, deploy to Layerbase Cloud for staging and production, replicate between them. That's exactly how I use it.

Option 3: Layerbase Desktop

Layerbase Desktop is the same SpinDB engine inside a desktop app. For CouchDB specifically, this is nicer than the CLI because the Fauxton web UI is one click away from the instance card. You don't have to remember http://127.0.0.1:5984/_utils or whatever port your instance ended up on.

It's a nice fit if you're building a CouchDB-backed app and want to inspect documents without leaving the GUI flow. For server work, the CLI is fine.

Option 4: Self-host on a VM

CouchDB's a single Erlang binary and a config file. It's not hard to self-host. The installer adds a systemd unit, the config lives in local.ini, and the data lives wherever you point it. You get to handle TLS, backups, monitoring, and node sizing yourself.

One gotcha worth flagging if you're doing this: CouchDB regenerates parts of local.ini on startup under certain conditions, which can clobber custom config. The fix is to put your changes in local.d/*.ini overlay files instead of editing local.ini directly. CouchDB merges everything in local.d after the base config, and those files don't get rewritten.

For a single-node deployment serving a small app, self-hosting is fine. For multi-node clusters with serious replication topology, the operational overhead of doing it yourself starts adding up fast.

Option 5: Neighbourhoodie

Neighbourhoodie is the consulting shop run by some of the people who actually write CouchDB. They don't sell managed hosting, but they sell expert help: migration support, performance tuning, custom design-doc work, and operational consulting. If you're at the scale where you need that kind of help, they're who you call.

Worth knowing about because it's the other commercial entity in the CouchDB ecosystem and it complements managed hosting rather than competing with it.

Migration notes

Migrating from Cloudant to anywhere else is genuinely straightforward because of CouchDB's replication protocol. The high-level steps:

  1. Stand up your new CouchDB instance (Layerbase, self-hosted, whatever).
  2. Create empty databases that mirror the names of your Cloudant databases.
  3. Trigger replication from Cloudant to the new instance:
bash
curl -X POST https://new-host/_replicator \
  -H "Content-Type: application/json" \
  -d '{
    "source": "https://APIKEY:PASSWORD@your-cloudant.cloudantnosqldb.appdomain.cloud/yourdb",
    "target": "yourdb",
    "create_target": true,
    "continuous": false
  }'

That kicks off a one-shot replication. For zero-downtime migrations, set continuous: true and the new instance stays in sync until you cut over your application.

Watch out for two Cloudant-specific things during migration:

Cloudant Query indexes are stored as design documents and replicate normally. Cloudant Search indexes (the Lucene-backed full-text ones) are a Cloudant-only feature and won't replicate to standard CouchDB. If you used them, you'll need to rebuild that functionality with a Mango index plus a separate full-text engine, or with CouchDB's built-in search if you're on a recent version.

Cloudant's per-account API keys don't translate. After migration, your application needs new credentials for the new instance. Plan for a deploy that updates the connection string at the same time as the cutover.

Which one to pick

Short version:

  • Need managed CouchDB hosting without IBM Cloud? Layerbase Cloud.
  • Coming off Cloudant Lite with a side project? Same place. It is not free, but it is a flat $15/mo with no metered reads, writes, or queries, and Pro has a 7-day trial if you want to run your workload against it first.
  • Building an offline-first app and want a local CouchDB for development? The Layerbase CLI.
  • Want the same thing in a desktop app? Layerbase Desktop.
  • Running a serious production CouchDB cluster and need expert help? Neighbourhoodie.
  • Have ops capacity and a small workload? Self-host on a VM.

CouchDB itself is in a good place. The 3.x release cycle has been stable for years, the replicator is bulletproof, and the offline-first ecosystem (PouchDB on the client, design-doc patterns on the server) is still the cleanest way to build sync-first applications. The thing that needed updating was the hosting market - a flat price you can predict, a serverless CouchDB option that scales to zero, and a path off Cloudant that takes one connection-string change. That's what Layerbase Cloud is finally doing.

If you want to dig deeper into CouchDB itself, the getting started guide walks through the document model, MapReduce views, Mango queries, and replication with a real TypeScript example.

Keep reading