LayerbaseLayerbase

Cloudant alternatives: managed CouchDB hosting and a free tier in 2026

CouchDBNoSQLDatabases

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 runs free, 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 "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 has a real CouchDB free tier with no credit card required. It includes a managed HTTPS endpoint, generated admin credentials, scale-to-zero hibernation, and the standard Apache CouchDB 3.x feature set (MapReduce views, Mango queries, replication, design documents, attachments). It is not a 30-day trial and it does not expire - it is the dev tier of a credit-billed product that remains free as long as you stay within the resource envelope. If you outgrow it, you only pay for the add-ons you turn on (keep-warm, larger storage, scheduled backups, region pinning). The CouchDB engine itself remains in the free pool.

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, that's the natural replacement for Cloudant Lite. Create one here.

Option 1: Layerbase Cloud

Layerbase Cloud hosts CouchDB as a managed engine. 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 for free instances. CouchDB cold-starts in under a second so the first request after idle 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, the "Keep alive" toggle on a paid instance disables hibernation.

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 SpinDB

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

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

Create and start:

bash
spindb create couch1 -e couchdb --start
bash
spindb 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 SpinDB installs is the real Apache CouchDB binary, not a re-implementation.

bash
spindb stop couch1
spindb start couch1
spindb list

A common pattern: develop locally against SpinDB, 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 Mac 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.
  • Looking for a free CouchDB tier or a Cloudant Lite alternative for a side project? Same place - the free dev tier doesn't expire and doesn't take a card.
  • Building an offline-first app and want a local CouchDB for development? SpinDB.
  • Want the same thing in a Mac 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 real free tier, 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.

Something not working?

Cloudant alternatives with managed CouchDB and a free tier | Layerbase Blog