DOCS: Clarification on Document DB Support Mentioned in Architecture Diagram

[jeevan0920]

While reviewing the Veraison architecture diagram, we noticed that Document Databases (such as MongoDB and CouchDB) are included as potential storage backends under the "Generic DB Interface" section.

Currently, we do not see any existing implementation or code that integrates Document DBs. We're trying to understand the intent and status of this part of the design.

---

1.Has the Veraison team evaluated the use of Document DBs, or is their inclusion in the architecture diagram purely illustrative?

We would like to understand whether their presence reflects:

• A planned or ongoing effort
• Consideration during the design phase as a future extensibility point
• Or simply a conceptual placeholder, without any concrete evaluation so far

---

2. Could Document DBs be a good fit for current KV-based endorsement storage?

Given that CoMID/CoRIM endorsements are naturally structured as JSON, we believe Document DBs might provide:

• A more direct representation of endorsement objects
• Simplified mapping compared to SQL schema (where JSONs are stored as strings)

We’re evaluating their suitability and would appreciate insights from the Veraison team.

---

3. Are there limitations in the current IKVStore interface that might make Document DBs unsuitable?

Would a Document DB backend be expected to conform strictly to the existing interface, or are there known incompatibilities or missing abstractions that would need to be addressed?

---

For additional context, we previously raised a related question regarding Graph DBs and received helpful clarification here:
🔗 #322

We’d appreciate any guidance on whether Document DBs are aligned with the Veraison architecture.

[setrofim]

1. The diagram should be treated as purely illustrative. We looked at document DBs at the same time as Graph DBs, during early prototyping, but have since been exclusively using SQL-based databases.
2. Givent the current IKVStore interface, document DBs, as a class, offer no significant advantages over relational DBs (technical merits of specific DBMS's may vary). Please note that representation of trust anchors/endorsemets as strings is currently part of the interface with the rest of the system, so even if they were stored as JSON documents in the DB, theywould still need to be converted to strings before being returned to the verifier. It should also be noted that some relational DBs (e.g. PostgreSQL) also have native JSON support, so switching to JSON representations for endorsements/trust anchors does not necissitate/necessarily advantage document DBs.
3. Not really. Given the simple key-value interface, there no particular advantages to document DBs, but the same goes for relationship DBs. That interface was specifically chose to be easily implementable regardless of the underlying technology. So a document DB (such as CouchDB) should work just as well as PostgreSQL (or some other relational DBs). We chose SQL-based DBs because it allows us to use sqlite for test/development deployments which simplifies the deployment as sqlite does not require installing/configuring a separate server.