The general guidance as that all peers on a channel should use the same database type to ensure deterministic endorsement and validation across peers.
We know that CouchDB itself places limitations on valid keys and even valid JSON content as documented here: https://hyperledger-fabric.readthedocs.io/en/latest/couchdb_as_state_database.html#state-database-options.
Therefore what may pass endorsement and validation on LevelDB may not pass validation on CouchDB.
Similarly, range queries used in transactions are validated at commit time on every peer to ensure the results at endorsement time still match current results, and although both LevelDB and CouchDB sort keys as bytes lexicographically, it is possible that in some edge cases LevelDB and CouchDB would return results in different order and therefore you could get different validation results (I don't know of any such edge cases, but I also haven't reviewed LevelDB and CouchDB source code to completely rule out any such cases).

You don't necessarily have to follow the general guidance however. If your chaincode data validation limits keys and values to what is supported on both LevelDB and CouchDB, there is no technical reason why you can't have both LevelDB and CouchDB based peers on the same channel.

BTW there is a Jira to add a channel capability that would enforce CouchDB data validation at endorsement time on all peers (not just CouchDB-based peers as is done in v1.4.x). See https://jira.hyperledger.org/browse/FAB-16355.


Dave Enyeart

"Siddharth Jain" ---12/24/2019 07:03:06 PM---this is the link where I read All peers on the network *must* use the same database type https://url

From: "Siddharth Jain" <siddjain@...>
To: fabric@...
Date: 12/24/2019 07:03 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] mixing CouchDB and LevelDB
Sent by: fabric@...