Cloudant alternatives: managed CouchDB hosting in 2026

Short version: the realistic Cloudant alternatives are Layerbase Cloud for managed CouchDB at a flat $15/mo with nothing metered, self-hosting on a VM if you have ops capacity and a small workload, and the Layerbase CLI or Layerbase Desktop if what you actually need is CouchDB on your own machine. Neighbourhoodie is the place to go for expert help rather than hosting. Whichever you pick, the move itself is one replication call, because CouchDB's replication protocol is universal.

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.

This article assumes you want to keep the CouchDB API and replication model. If you are considering a different database entirely, CouchDB alternatives in 2026 compares Couchbase, RxDB, Firestore, MongoDB, PostgreSQL, and SQLite/libSQL by the behavior they replace.

Contents

• The options at a glance
• Why people leave Cloudant
• Coming from the Cloudant Lite free tier?
• Option 1: Layerbase Cloud
• Option 2: Run it locally with the Layerbase CLI
• Option 3: Layerbase Desktop
• Option 4: Self-host on a VM
• Option 5: Neighbourhoodie
• Migration notes
• Which one to pick
• FAQ

The options at a glance

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.

Cloudant's Lite and Standard database-count caps and the ~$1/GB/mo storage rate past the included 20 GB were verified 2026-08-25 from IBM's Cloudant documentation. The Standard entry figure is the last one we confirmed from IBM's catalog rather than a rate we re-fetched today, so treat it as approximate. Create a managed CouchDB 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.

curl https://admin:password@<your-host>.cloud.layerbase.dev/

{"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?)

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

Create and start:

lbase create couch1 -e couchdb --start

lbase url couch1

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.

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:

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.

FAQ

Is there a free managed CouchDB hosting service?

Cloudant Lite is the only real free managed CouchDB, and it comes with 1 GB of storage, throughput throttles, and a hard 20-database cap on instances created after March 3, 2025. Layerbase Cloud does not have a free CouchDB; managed CouchDB starts on the Pro plan at $15/mo with a 7-day trial. Running CouchDB locally with the Layerbase CLI is free, but that is a development instance, not hosting.

What is the best Cloudant alternative?

For most people leaving Cloudant it is Layerbase Cloud, because it is managed Apache CouchDB with a flat bill and no IBM Cloud account. If your workload is small and you enjoy ops work, self-hosting on a VM is cheaper in dollars and more expensive in time. If you need help rather than hosting, Neighbourhoodie is the consulting shop staffed by CouchDB committers.

Can I move off Cloudant without downtime?

Yes. Point a _replicator document at your Cloudant database with continuous: true, let the new instance catch up and stay in sync, then deploy the connection-string change whenever you are ready. The switch is a deploy, not a maintenance window.

What does not survive a migration off Cloudant?

Two things. Cloudant Search indexes, the Lucene-backed full-text ones, are a Cloudant-only feature and do not replicate; you rebuild that with a Mango index plus a separate search engine. Cloudant's per-account API keys also do not translate, so the new instance needs fresh credentials issued at cutover. Cloudant Query indexes are stored as design documents and replicate normally.

Does Layerbase Cloud run real Apache CouchDB?

Yes, the upstream binary unchanged, which is why the same client libraries, MapReduce views, Mango queries, design documents, and attachments all behave the way the CouchDB docs say they do. There are no Layerbase-specific CouchDB features to learn and nothing proprietary to unwind if you leave.

How does scale-to-zero work for CouchDB?

A CouchDB instance hibernates after six idle hours and wakes on the next request. CouchDB cold-starts in under a second, so the first request back is barely noticeable, and if you have continuous traffic it never happens at all. If you would rather skip the hop entirely, 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 billed separately.

Where to start

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. If you are ready to move, create a managed CouchDB and replicate one database into it before you commit to anything.