Hyperledger Fabric CouchDB state database: what the integration does
CouchDB is the supported alternative to the default LevelDB state database in Hyperledger Fabric, and it runs as a separate database process alongside each peer. The block files and transaction history stay on the peer. Only the world state, the current value of each key, moves into CouchDB, which allows the peer to answer richer queries against that state. Consider an illustrative consortium member whose peers must answer reporting questions from a regulator or an internal audit team, such as listing all transfers above a set threshold for one counterparty over a period. That kind of question is the situation this integration addresses. Before any work starts, the member should write down the queries it needs and check each one against what LevelDB can serve.
The choice is made per peer and per channel, so the consortium has to decide the state database for each channel and each peer that joins it. The Fabric docs name CouchDB as the option for auditing and reporting requirements that LevelDB does not meet, which is the main reason to accept an extra process. The deployment guide also says channels should not have peers using both CouchDB and LevelDB, because CouchDB imposes restrictions on keys and values that LevelDB does not. A consortium should therefore agree the database type for each channel during channel design and check every organization's peers against that agreement before they join.
Running CouchDB adds a stateful component to each peer. It has its own process, configuration, storage and upgrade cycle, so the operations team takes on one more service per peer to monitor, back up and recover. The restrictions on keys and values matter most at design time. The Fabric CouchDB docs describe a default max_document_size of 8 MB as of CouchDB 3.0.0, which can be raised to 4 GB. The data model should be reviewed for the size of its documents before data is written to the channel. Moving a channel from one state database type to the other later is a separate piece of work, so the team should confirm the exact procedure in the Fabric docs for its release line before relying on it.
Before committing, the member should confirm four things: the list of reporting queries and whether LevelDB can answer them, whether any channel it plans to join already mixes database types, the document sizes its data model produces, and which team owns the CouchDB process on each peer. Ask the consortium operator to record the state database choice for each channel in the channel design, and to confirm which CouchDB version the Fabric release line in use supports. These answers show whether the extra process is justified, and they set the scope for the configuration, indexing and backup work that follows.
What you need before enabling CouchDB on a Fabric peer
Enabling CouchDB as a peer state database adds a separate database process, its own storage and its own credentials to each peer. The items below are the decisions and resources to settle before the first peer changes, so the rollout does not stall on a version or channel question partway through.
A chosen Fabric release line
Decide between the 2.5 LTS line and the 3.x line before any configuration work starts. The Fabric documentation identifies v2.5 as the long-term support release for production users, while 3.x receives patch releases in parallel. The CouchDB settings you apply depend on the release, so record the exact Fabric version each peer runs and check the supported CouchDB version for that release in the Fabric docs rather than assuming one.
A CouchDB deployment and monitoring plan
Each peer needs its own CouchDB process running alongside it, so decide whether it runs as a container, a package on a host or a workload on your cluster. Define how each instance is started, restarted, health checked and tied to the peer's lifecycle. Confirm that your monitoring can observe CouchDB separately from the peer, because a healthy peer does not prove its state database is responsive.
The channels that will use CouchDB
Fabric's deployment guidance says that no channel should have peers using both CouchDB and LevelDB, because CouchDB imposes restrictions on keys and values that LevelDB does not. List every channel each peer joins and mark which ones move to CouchDB as a whole. A peer that serves a mixed set of channels needs this decision made per channel before enablement, not after.
Approved CouchDB images or packages
Identify where the CouchDB binaries or container images will come from and how they are approved and patched. Fabric's prebuilt images are a starting point, but your organization may require images from an internal registry with scanning and signing. Confirm the image tag or package version against the Fabric documentation for your release line, and plan how you will test and roll out CouchDB patch releases.
Storage capacity for database files
CouchDB stores the world state and its indexes in files that grow with the ledger, and index files add to that footprint. Ask the team that owns storage to size volumes for each peer, leave headroom for growth and compaction, and confirm that the volumes are backed up on a schedule that matches your recovery targets. Storage that is shared across peers can turn a single fault into several.
TLS and credential handling for CouchDB
The peer connects to CouchDB with a username and password, so decide how those credentials are created, stored and rotated before enablement. The Fabric docs describe changing the user and password after the container is created through the local.ini configuration approach, which means the secret must reach the process without being baked into images. Plan the TLS configuration for the CouchDB endpoint and confirm who holds the secrets and how access is audited.
When CouchDB is worth the extra process over LevelDB
Choose CouchDB only when the network needs rich queries or reporting that LevelDB cannot serve. CouchDB runs as a separate database process alongside each peer, so it is an operating commitment, not a configuration switch. Every peer that uses it needs its own storage, patching, backups and monitoring, and the team must be able to run that work across every member organization that operates a peer on the channel.
The Fabric CouchDB documentation says CouchDB can help meet auditing and reporting requirements that LevelDB does not support. In practice the justification usually comes from a written requirement: an examiner or internal audit function that needs to query ledger state by attributes such as account, status or date range, a regulator that expects periodic reports drawn from world state, or an operations team that must answer ad hoc questions without writing a client application for each one. Ask each member organization to name the query, who runs it, how often, and what happens if the answer is slow or unavailable.
A team with no rich query or reporting requirement should default to LevelDB unless the Fabric docs or its own assessment point the other way. Choosing LevelDB does not remove the need for ledger backups, but it removes a database process, its credentials, its index maintenance and its upgrade cycle from every peer. Record the decision and the query requirements that drove it, so a later request for reporting can be assessed against a documented baseline.
Do not mix database types within a channel. The Fabric deployment guide says channels should not have peers using both CouchDB and LevelDB, because CouchDB imposes restrictions on keys and values that LevelDB does not. A key or value that LevelDB accepts can fail on a CouchDB peer, so a mixed channel can diverge in what it stores and how it behaves. Confirm this rule against the current Fabric docs before the first peer is provisioned, and make the database type part of the peer configuration standard that every member organization must follow.
Before committing, confirm three things with the Fabric team and with your own assessment: which queries and reports must run against ledger state, whether your data model and chaincode values fit CouchDB's limits, and who in each member organization will own the CouchDB process after go-live. If those answers are unclear, the safer choice is LevelDB now, with a documented plan to revisit when a reporting requirement is confirmed.
How to configure CouchDB as the Hyperledger Fabric state database
This sequence takes a peer from LevelDB to CouchDB as its state database without mixing database types on a channel. Each step ends with a check, so the team knows the peer is reading and writing state in CouchDB before indexes and reporting queries are added.
Select the channels and peers that will use CouchDB
Before any change, list every channel and every peer that joins it. The Fabric deployment guide says a channel should not have peers using both CouchDB and LevelDB, because CouchDB imposes restrictions on keys and values that LevelDB does not. Decide per channel, not per peer, and record which peers will move together. Check the result by inspecting each candidate peer's core.yaml and confirming that the state database setting is LevelDB on every peer that will stay on a channel, and that no CouchDB-backed peer shares a channel with a LevelDB peer. Agree this list with the other member organizations on each channel, since their peers are part of the same ledger.
Deploy a CouchDB instance beside each peer
Run CouchDB as a separate database process alongside each peer that will use it, as the Fabric CouchDB documentation describes. The peer and its CouchDB should share a trusted network path, and CouchDB should not be reachable from other networks. Confirm the CouchDB version against the Fabric documentation for your release line before choosing an image. Check the result by confirming that the CouchDB service starts, that its root endpoint responds from the peer's host or container, and that it is reachable only from the peer and approved administrators.
Set CouchDB administrator credentials in local.ini
Set the CouchDB administrator user and password through the local.ini configuration approach, not by changing them after the container exists. The Fabric docs state that changing the user and password after the CouchDB container is created requires this approach, so building the credential into configuration at deploy time avoids a rotation problem later. Store the password in your secrets manager and inject it at deploy time rather than writing it into a shared file. Check the result by confirming that an authenticated request with the new credentials succeeds and an unauthenticated request to the admin endpoints is refused.
Point the peer state database settings at CouchDB
In the peer configuration, change the state database setting from LevelDB to CouchDB and set the CouchDB address, the administrator user and the password reference. Keep the peer's other ledger settings unchanged in this step so that any later fault has one cause. Confirm the document size limit with the CouchDB version you run: the Fabric CouchDB docs say that from CouchDB 3.0.0 the default max_document_size is 8 MB and can be raised to 4 GB. Check the result by reviewing the effective peer configuration file and confirming the address and credential reference match the CouchDB instance from the previous steps.
Start the peer and confirm the state database type
Restart the peer with the new configuration and watch its startup logs. Look for messages showing that the peer connected to CouchDB and created or opened its state databases for each joined channel, and for any error about authentication, connection refused or document limits. Confirm that the peer's operations service reports healthy using the /healthz endpoint, which is secured with mutual TLS client certificates. Check the result by confirming that the logs name CouchDB as the state database for every channel on this peer and that no LevelDB state store is being used for those channels.
Confirm state writes and reads on each channel
Run a transaction on a test channel and check that world state is written to CouchDB. Use the CouchDB HTTP interface from an approved administrator host to list the databases created for the channel and confirm that a document exists for the key the transaction wrote. Repeat this for each channel the peer joined. Check the result by confirming that the document count and key names match what the transaction should have produced, and that the peer logs show no errors during the test.
Create indexes for reporting queries
Add CouchDB indexes only for the rich queries your chaincode and reporting tools actually run, and define them in the chaincode package so every peer that installs the chaincode gets the same indexes. CouchDB is useful here because it supports auditing and reporting that LevelDB does not. Document each index against the query it serves, since unused indexes add write cost. Check the result by running each reporting query against a peer on the channel and confirming that the query returns the expected records and that the peer logs show the index being used rather than a full scan warning.
How Fabric ledger data maps to CouchDB documents and indexes
This table maps the Fabric concepts a team designs for to their CouchDB counterparts, from channels and keys to documents, size limits and indexes. Rows marked for confirmation depend on your chaincode data model, so check them against your own assets and queries before build starts. The main takeaway is that CouchDB reporting queries are only as sound as the keys, document sizes and indexes you package with each chaincode.
| Fabric concept | CouchDB counterpart | What the team must design | Confirm against chaincode |
|---|---|---|---|
| Channel | One CouchDB database per channel and chaincode namespace on each peer | Set the state database type per channel before go-live | No, set by network design |
| Database type on a channel | CouchDB or LevelDB for all peers on the channel | Do not mix CouchDB and LevelDB peers on one channel | No, set by network design |
| Key | Document _id | Use a key scheme that satisfies CouchDB key restrictions and supports lookups | Yes, confirm key naming per asset type |
| Value | JSON document body | Store values as JSON when they must be queried; non-JSON values cannot be filtered | Yes, confirm value shape and fields used in queries |
| Document size | max_document_size, 8 MB by default from CouchDB 3.0.0, raisable to 4 GB | Confirm the largest value per asset and keep large payloads off the ledger where possible | Yes, confirm largest expected value |
| Query needs | Mango query indexes on document fields | Define one index per query pattern, since each index adds write cost | Yes, confirm the query patterns each chaincode serves |
| Index packaging | Index definitions deployed with the chaincode package | Version indexes with each chaincode release and test them on peers | Yes, confirm index files match the data model |
Designing indexes for reporting queries on Fabric data
Start index design from the reporting questions, not from the data model. Before anyone writes an index definition, the team should list every reporting query that will run against the peer's CouchDB state database, including the fields each query filters on and sorts by, how often it runs and which business user or system depends on it. CouchDB answers a selector query efficiently only when an index covers the fields the query uses. A query without a matching index still returns results on a small ledger, but it becomes a full scan as the state grows, and that scan competes with transaction validation on the same peer. The reporting list is therefore the input to every later index decision.
Each index is a cost that the team pays for on every write. When a transaction updates a key, the peer must also update every index that includes a changed field, and each index consumes disk space on the CouchDB side. The Fabric CouchDB documentation describes CouchDB as a separate database process that can meet auditing and reporting needs LevelDB does not support, but that benefit comes with these ongoing costs. Keep the index set as small as the reporting list requires. Ask whether a query can be answered with an existing index by changing field order or query shape before adding another index, and record which query each index serves so that unused indexes can be retired later.
Index definitions belong in the chaincode package. Fabric lets a chaincode package include index files under META-INF/statedb/couchdb/indexes, and the peer creates those indexes when the chaincode is committed to a channel. This keeps indexes versioned with the chaincode that writes the data, so a change to a query and its index can go through the same review, approval and channel upgrade process as a code change. Confirm the exact directory layout and the behavior on chaincode upgrade against the current Fabric version your network runs, since the lifecycle is part of your change control. Also confirm how existing indexes are handled when a new package version drops or renames an index.
Test every index against the reporting queries before it reaches production. Build a non-production network that uses CouchDB on its peers, load it with a dataset close in size and document shape to production, and run each reporting query with the expected selector, sort and limit. Check the query plan or response behavior, the time each query takes and the effect of the index on write latency during a representative batch of transactions. Include the queries that your application issues internally, because an index added for reporting can also change how those queries behave. Record the results so that the decision to add or change an index can be traced later.
Plan for the effects of the index set on operations. Each new index increases the state database storage that backups and restores must handle, and it lengthens the time needed to rebuild a peer's CouchDB state. Include the index files in your change records and in the runbook for peer recovery. Ask your implementation partner to show how the test network was sized, how representative the data volume was and which queries were excluded from testing, and agree with your compliance and reporting owners on the list of queries that must keep working after each chaincode upgrade.
Securing CouchDB credentials, network paths and peer access
CouchDB holds the peer's world state, so its credentials, network reach and data access need the same care as the peer itself. The controls below work together: each one narrows who can read or change state, and the last one keeps those controls correct after a peer rebuild.
Administrator and user credentials in local.ini
Set the CouchDB administrator and any application user credentials in the local.ini configuration file that the peer's CouchDB process reads. The Fabric docs note that changing the CouchDB user and password after the container has been created requires this local.ini approach, so plan it into the first build. Confirm the exact sections and file path against the CouchDB and Fabric docs for your CouchDB version before you write the file.
Keep secrets out of images and source control
Credentials written into a container image or committed to a Git repository are copied to every place that image or repository reaches, and they are hard to recall once spread. Inject the local.ini values at deploy time from your secrets store, and confirm that build logs, image layers and Helm or Compose files contain only references. Scan repositories and images for CouchDB passwords as part of the release pipeline.
Restrict network paths to the owning peer
Allow connections to each CouchDB process only from the peer it serves, and block other peers, client applications and administrative hosts at the network layer. The peer's operations service also uses mutual TLS client certificates for its /healthz and /metrics endpoints, which is a separate control on the peer. CouchDB does not inherit that setup, so check its listener and firewall rules on their own.
TLS for CouchDB connections
Encrypt traffic between the peer and its CouchDB process where your CouchDB and Fabric versions support it, and confirm the supported configuration in the CouchDB and Fabric documentation before you commit to a design. Decide whether certificates come from your own CA, how they are renewed, and where private keys are stored. Test peer startup and state queries after enabling it, because a certificate mismatch appears first as a failed connection.
Least-privilege access to data and backups
Restrict read and write access to the CouchDB data directory to the service account that runs it, and give backup jobs read access only to the copies they need. Backups of state databases carry the same confidentiality as the ledger data they mirror, so encrypt them and limit who can restore. Record who is allowed to restore a peer's state, because restoring a copy into the wrong peer is a data integrity risk.
Rotate secrets when a peer is rebuilt
Issue new CouchDB credentials each time a peer is rebuilt, and revoke the previous ones in the secrets store once the new peer is serving. Check that the rebuilt peer's local.ini matches the new values, and that no backup job, script or monitoring agent still holds the earlier password. Agree the rotation procedure and its owner before the first rebuild, so it is ready when an incident forces a rebuild.
Common failures when CouchDB backs a Fabric peer
This table lists the failures most often seen when CouchDB serves as a Fabric peer's state database, with the cause and a concrete check for each. Use it as a triage list during build and as a runbook entry during operations. Most failures trace back to configuration drift, channel mixing, or data that outgrew a default.
| Failure | Likely cause | Check and fix |
|---|---|---|
| Peer and CouchDB mixed on one channel | Some peers on the channel use CouchDB and others use LevelDB, so the channel has two state database types | Confirm each peer's state database setting and align all peers on the channel to one type. Fabric guidance says CouchDB imposes key and value restrictions that LevelDB does not, so review chaincode keys against those rules before switching |
| Document exceeds the 8 MB default limit | CouchDB 3.0.0 and later default max_document_size is 8 MB, and a state value or chaincode-written document is larger | Search peer and CouchDB logs for document size errors, then review the value size in chaincode. Raise max_document_size in local.ini only if the data model genuinely needs it, since the documented ceiling is 4 GB |
| Peer cannot connect after CouchDB credentials change | The CouchDB user or password was changed inside the container after creation, so the peer still uses the old values | Compare the credentials in the peer's core.yaml or environment with the CouchDB local.ini values. Update the configuration approach documented for changing the user and password after container creation, then restart the peer and check its log for successful state database connection |
| Reporting query slow or failing | No index exists for the query fields, so CouchDB scans documents at request time | Run the query with its selector and check the peer or CouchDB logs for warnings about missing indexes. Create a JSON index on the fields used in the selector and sort, then retest. Confirm index definitions are packaged with the chaincode so every peer creates them |
| CouchDB storage filling up | Ledger growth, index growth, and CouchDB database compaction not keeping pace, with no capacity alert on the data volume | Monitor disk use on the CouchDB data volume and track growth per channel database. Confirm compaction settings with your CouchDB version documentation, add alerts well before the volume fills, and plan extra capacity from measured growth rather than assumption |
| Restored peer state database no longer matches the ledger | The CouchDB database was restored from a different point than the peer's block storage, or was deleted and not rebuilt | Compare the block height in the peer log with the state database contents after restart. Where the two disagree, rebuild the state database from the ledger using the procedure in the Fabric docs for your release, and test restores on a non-production peer first |
Sizing storage and backing up CouchDB alongside the ledger
Size CouchDB from measurements taken in your own network, not from a general rule. The state database on each peer holds the current world state, so its footprint depends on how many keys the channel holds, how large the JSON documents are, how many indexes the peer maintains for reporting queries, and how many peers in your organization run CouchDB for the same channel. Each index adds write and storage cost, and each peer keeps its own copy of the state. Before you fix disk, memory and volume sizes, run your chaincode against a representative data set on a test network, record document sizes and key counts, and measure how the database grows over a realistic period of transactions. Confirm the per-document limit that applies to your CouchDB version, since the Fabric CouchDB guide notes a default max_document_size of 8 MB that can be raised, and design your data model so documents stay well inside whichever limit you choose.
Plan backups for CouchDB as part of the ledger backup, not as an afterthought. The Fabric upgrade guide starts with backing up the ledger and MSPs before any binary changes, and the CouchDB state is a separate database process that holds its own copy of the world state. Your backup plan should name the peer data directories, the CouchDB data volumes, the local.ini configuration and the MSP material, and say how each is captured and restored. Note that the world state can be rebuilt from the block files on a peer, so the CouchDB backup mainly shortens recovery time. Decide which of these you will rely on and write that decision down before you need it.
Confirm the supported backup approach for your CouchDB version in the Fabric documentation before you choose tooling. The CouchDB as the state database page describes how the state database is configured and maintained, and the approach you adopt must match that guidance and the CouchDB release your peers run. Do not assume that a volume snapshot of a running database is consistent. Check whether the Fabric docs require the peer to be stopped, whether CouchDB offers a supported dump or replication method, and how the peer resumes after restore.
Test the recovery method by restoring to a separate peer, not by reviewing the procedure on paper. Stand up a spare peer in a non-production environment, restore the ledger, MSPs and CouchDB data from your backups, and confirm that the peer joins the channel, reports the expected block height and answers the chaincode queries your business depends on. Time the restore and record every manual step, because those steps become your runbook. Repeat the exercise after each Fabric or CouchDB upgrade, and after any change to indexes or document size limits. A backup that has never been restored is an assumption, and auditors and your own incident team will expect evidence that it works.
Questions teams ask before running CouchDB with Fabric
What drives the cost of running CouchDB as the Fabric state database?
The main cost drivers are the number of peers and channels that use CouchDB, the volume of state data per channel, how many indexes the reporting queries need, and how much backup and restore testing the network requires. Each peer runs its own CouchDB process, so a network with more peers or more channels has more databases to design, configure, back up and monitor. Index design matters because every index adds build time and storage. When you request a quote, ask the partner to break the scope down by peer count, channel count, expected state size, the list of query patterns that need indexes, and the restore test you expect to see documented. A fixed scope agreed in writing lets you compare those items directly with an internal estimate.
Which parts of a CouchDB on Fabric project are one-time and which recur?
One-time work usually includes the database design, the index build for known reporting queries, the initial configuration of each CouchDB instance, and the first restore test that proves backups can be recovered into a working peer. Recurring work includes patching CouchDB and Fabric releases, watching capacity as ledger state grows, keeping monitoring and alerts current, and running upgrades when the network moves between Fabric lines. Upgrades are a recurring cost that many teams underestimate. The Fabric upgrade guide describes backing up the ledger and MSPs before changing binaries, so the backup and restore process has to be repeated for each upgrade cycle. Ask the partner which items are priced once and which are covered by an ongoing support arrangement.
What does the client need to provide for a CouchDB on Fabric engagement?
You need to provide network access to the peer hosts and the CouchDB instances, storage with enough capacity and performance for the state database and its backups, and change windows for restarts and upgrades. You also need staff who can operate CouchDB and Fabric after handover, including people who can read logs, rotate credentials and respond to alerts. Credentials for CouchDB sit in the peer configuration, so your security team should decide where those secrets are stored and who can change them. Confirm these requirements early with your infrastructure and security teams, because a missing network path or unavailable change window can delay the work more than the technical design does.
Can an internal team run CouchDB with Fabric without a partner?
Yes, an internal team can do this if it has working knowledge of Fabric peers and channels and of database operations, including CouchDB configuration, indexing, backup and restore. The Fabric documentation is the reference for the peer configuration, the CouchDB state database settings and the rule that channels should not mix CouchDB and LevelDB peers. The questions to answer honestly are whether the team has run a restore of a CouchDB state database before, whether it can own upgrades on a set schedule, and whether it has someone on call for the database layer. If the answer to any of these is no, the gap is usually the restore testing and upgrade planning rather than the initial setup.
Why would a network choose CouchDB over LevelDB for the state database?
Choose CouchDB when you need rich queries against the state database for auditing or reporting, which LevelDB does not support in the same way. CouchDB runs as a separate database process next to each peer, so it adds an operational component that LevelDB avoids. The trade-off is more process to patch, monitor and back up, plus restrictions on keys and values that LevelDB does not impose. If your reporting needs can be met from application data or an off-ledger store, LevelDB may keep the network simpler. Make this decision per network before the build starts, because the Fabric guidance is to keep one database type per channel.
How does DeployOpen scope a CouchDB on Fabric engagement?
DeployOpen scopes the work in writing before it starts. The scope covers the systems in your own infrastructure, the peers and channels that will use CouchDB, the index and query requirements, the backup and restore test, the monitoring and the handover to your team. The written scope lists deliverables, timelines and the client responsibilities described above, and changes go through a documented scope change. DeployOpen does not publish a price list, so a quote follows from the agreed scope. Ongoing support, upgrades and testing can be arranged as a retainer if your team wants a partner for recurring work after the initial build.
What should the design decide before any CouchDB installation starts?
Decide which channels will use CouchDB, confirm that no channel mixes CouchDB and LevelDB peers, and list the reporting queries that need indexes. Also decide where CouchDB credentials are stored, since changing the CouchDB user and password after the container is created requires the local.ini configuration approach according to the Fabric docs. Set the maximum document size deliberately, because CouchDB 3.0.0 has a default max_document_size of 8 MB that can be raised to 4 GB. Finally, define how backups are taken, where they are stored, and how a restore is tested. Writing these decisions down early makes the quote and the build sequence much easier to compare.
How DeployOpen works on this
DeployOpen plans the CouchDB state database as part of the Fabric network design from the first session. We confirm early whether CouchDB is worth the extra process for your reporting and audit needs, then keep every peer on a channel on the same database type. The work runs inside your own infrastructure, and the written scope sets out what is built, tested and handed over.
How we scope
- The written scope lists each channel and confirms every peer on it uses the same state database type.
- Scope lists the reporting queries that need CouchDB indexes and the document sizes your chaincode will write.
- Engagements are fixed-scope, with deliverables agreed in writing before work starts.
How we build
- Run CouchDB as a separate process beside each peer, with credentials in local.ini so they can be changed later.
- Keep the 8 MB default max_document_size unless testing shows a raised limit, up to 4 GB, is needed.
- Design indexes for reporting queries with the chaincode team, and test each query before go-live.
How we hand over
- Hand over a runbook covering CouchDB credentials, the one-database-type-per-channel rule and index inventory.
- Provide backup and sizing notes for the CouchDB data alongside the ledger and MSP backups the upgrade steps require.
- Document test results, configuration and access settings so your own operators can run the database after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for the CouchDB layer and the network around it.
- Review the database choice per channel when reporting or audit needs change, keeping one database type on each channel.
- Follow the Fabric upgrade steps for each release, starting with a ledger and MSP backup.
