LayerbaseLayerbase

Serverless CouchDB in 2026: scale-to-zero managed Apache CouchDB

CouchDBServerlessNoSQLDatabases

"Serverless CouchDB" is a phrase people search for when they want managed Apache CouchDB hosting without thinking about node counts, capacity sliders, or operating-system patches. The category has been narrow for a long time. IBM Cloudant has been the only mainstream hosted option since 2014. Self-hosting on a VM is fine for small apps but is not serverless in any meaningful sense. PouchDB is a client-side library, not a hosted server.

In 2026 the category finally has a second entrant: Layerbase Cloud hosts Apache CouchDB on a serverless model with a real free tier, scale-to-zero hibernation, and no database-count cap inside the storage envelope. This post covers what serverless CouchDB actually means, what the trade-offs are, and how to ship on it.

Contents

What "serverless" means for CouchDB specifically

The word "serverless" gets used loosely. For a managed database, the practical traits people are looking for are:

  1. No node count to manage. You do not pick "small / medium / large" or "1 vCPU 2 GB". You hit a URL and it works.
  2. Pay only for what you use. Idle workloads do not accrue charges, or accrue trivially small ones.
  3. Automatic scale-up to handle bursts. A traffic spike does not require manual intervention.
  4. Scale-to-zero for hibernating instances. A demo app that nobody is using right now should not cost money.
  5. Managed durability, backups, and TLS as defaults, not opt-ins.

CouchDB is unusually well-suited to this model because it is a single Erlang process per node, starts up in well under a second, persists everything through normal disk I/O, and exposes everything over HTTPS without a wire protocol of its own. There is no "warm pool" of connections to maintain, no JDBC driver tuning, no replication-set quorum to negotiate. Cold-starting a CouchDB is roughly as fast as starting any other HTTP service.

That makes scale-to-zero practical on CouchDB in a way that it is not for, say, an Elasticsearch cluster or a Postgres primary-replica setup.

Why the category has been so narrow

CouchDB itself is great. The HTTP-native API, the universal replication protocol, the offline-first ergonomics, and the conflict resolution model all hold up better than people give them credit for. What kept the category small was that hosting it was niche.

IBM Cloudant was the dominant managed CouchDB for over a decade. It is solid technology, but the pricing model is provisioned-capacity (you pay for reserved reads/s, writes/s, queries/s, plus storage), which is the opposite of serverless. The Lite free tier is throttled and capped at 20 databases since March 2025, and the jump to the Standard plan starts at around $77/mo.

PouchDB is excellent on the client side and replicates against any CouchDB, but it is not a hosted product, it is a JavaScript library. Couchbase is a different database that shares some heritage but not the API.

That left "rent a VM, install CouchDB, manage it yourself" as the de-facto path for small workloads that did not want to live on Cloudant's capacity model. Workable, but not serverless.

Layerbase Cloud is the first hosted Apache CouchDB that treats serverless as the default operating mode rather than an enterprise feature.

Scale-to-zero and cold starts

The most visible serverless behaviour on Layerbase Cloud is scale-to-zero hibernation. After an idle window, the CouchDB instance is hibernated. The data stays on disk; the process is paused. The next incoming request wakes it up.

Cold start times are short because CouchDB itself starts fast. In practice, the first request after hibernation takes under a second to complete (most of that is the wake-up; the request itself is normal CouchDB latency). For continuously-used workloads, hibernation never triggers and there is no cold-start cost. For spiky workloads, the first request after a quiet period is slower; subsequent requests are normal.

If you want to disable hibernation entirely, that is a paid add-on (keep-warm). The default is scale-to-zero because the free tier exists primarily for hobby projects, dev environments, and demos, all of which are fine with a sub-second cold start.

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

A hibernated instance answers that request in roughly 700ms (the wake) the first time, then a few milliseconds for subsequent requests until it hibernates again.

Offline-first apps: the canonical fit

The killer use case for serverless CouchDB is offline-first applications. The pattern looks like this:

  1. Client side: PouchDB running in a browser, mobile app, or desktop app. The user reads and writes to PouchDB locally with no network requirement. The app feels instant because everything is on-device.
  2. Server side: Apache CouchDB running serverlessly. Each user (or each tenant, or each device) has its own database.
  3. Sync: PouchDB replicates against CouchDB continuously when the network is available, both pushing local writes and pulling remote ones. Conflicts are resolved by CouchDB's revision tree.

The serverless property matters because in a real offline-first app, the server-side database is idle most of the time. Each user's database receives sync traffic only when their device is online and changed, which might be a few seconds per hour. Paying for a continuously-provisioned database per user is wasteful. Scale-to-zero plus per-database hibernation lines up exactly with the access pattern.

For an app with thousands of users, this means thousands of CouchDB databases that are mostly idle and occasionally hot, and the bill scales with active sync traffic rather than user count.

This is the architecture that historically lived on Cloudant. With the 20-database cap on Cloudant Lite and the 200-database cap on Cloudant Standard, that pattern is harder to bootstrap on Cloudant now. On Layerbase Cloud's free tier, the cap is total storage, not database count.

Layerbase Cloud free tier walkthrough

Here is the full path from zero to a working serverless CouchDB.

  1. Create the instance. Click here, pick CouchDB. No credit card. You get a URL like https://admin:GENERATED_PASSWORD@your-host.cloud.layerbase.dev.

  2. Verify it works.

bash
curl https://admin:GENERATED_PASSWORD@your-host.cloud.layerbase.dev/
json
{"couchdb":"Welcome","version":"3.5.0","features":["access-ready","partitioned","reshard","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}
  1. Create a database.
bash
curl -X PUT https://admin:GENERATED_PASSWORD@your-host.cloud.layerbase.dev/notes
  1. Write a document.
bash
curl -X POST https://admin:GENERATED_PASSWORD@your-host.cloud.layerbase.dev/notes \
  -H "Content-Type: application/json" \
  -d '{"title": "First note", "body": "Hello, CouchDB"}'
  1. Connect a PouchDB client.
ts
import PouchDB from 'pouchdb'

const local = new PouchDB('notes')
const remote = new PouchDB(
  'https://admin:GENERATED_PASSWORD@your-host.cloud.layerbase.dev/notes',
)

await local.sync(remote, { live: true, retry: true })

await local.put({ _id: 'note-1', title: 'Offline write' })

That is a complete offline-first sync setup. The browser writes locally to IndexedDB through PouchDB; the sync replicates to the Layerbase CouchDB when the network is available; the same data flows back if another device made changes.

  1. Browse documents in Fauxton. Click the instance's "Fauxton" button on the Layerbase Cloud dashboard, or go to https://your-host.cloud.layerbase.dev/_utils. Same UI as upstream CouchDB.

For a fuller walkthrough including MapReduce views and Mango queries, see Getting started with CouchDB.

When serverless CouchDB is the wrong choice

Serverless is the right shape for a lot of workloads, not all of them. Cases where it is the wrong call:

  1. Sustained, high write throughput with no idle windows. If your database is always hot, scale-to-zero never helps. A reserved-capacity model like Cloudant Standard or a self-hosted cluster ends up cheaper and more predictable.
  2. Strict-latency requests where a 700ms cold start is unacceptable. Real-time trading, telemetry ingestion under load, anything where the 99th percentile of the first-request-after-idle is in your latency budget. Keep-warm is a paid add-on that fixes this, but if you need it always-on, "always-on" is what you should pay for.
  3. Apps that do not actually need CouchDB. "I want a managed JSON store" is not the same as "I want CouchDB." MongoDB Atlas, FerretDB, or a Postgres JSONB column may be a better fit. CouchDB shines specifically when you want offline-first sync, multi-master replication, or the database-per-tenant pattern.
  4. Apps that lock to Cloudant-specific features. Cloudant Search (Lucene-backed full-text inside design documents) does not exist in upstream Apache CouchDB. If your app depends on it, see the migration guide for the workaround using Meilisearch.

For everything else, serverless CouchDB is a genuinely nice place to live. The HTTP-native interface, the universal replication protocol, the offline-first ergonomics, and the new scale-to-zero hosting option line up cleanly.

Where to go from here

CouchDB has always been the right answer for a specific kind of application. The thing that was missing was a serverless host for it. That gap finally closed in 2026.

Create your free CouchDB on Layerbase Cloud and have a working endpoint in under a minute.

Something not working?