We are exploring the usability of JCR API for our application, while searching the web I came across this article, from Nuxeo, where they mentioned the below point as the main reason for them to drop JCR.
Opacity of the in-database storage. We wanted data stored in a SQL database to be real SQL tables with visible data. This is helpful for many things, be it imports, backups, debugging, etc. While the goal of JCR to be the "SQL of content" is noble, the reality is that all our customers want data to be in a SQL database, not in something they don't know. We had had previously the same problem with Zope and its ZODB btw. Serializing Java objects in database columns is really not our idea of a clean storage.
Though that article is very old, I want to know whether that point, regarding opacity of storage, is still true in case of Jackrabbit OAK or ModeShape.
The RDB persistence of Jackrabbit OAK serializes documents basically in JSON. The raw DB content isn't easily decoded though, because sometimes write operations are serialized as diffs, and the main JSON body might be compressed. Furthermore, binary content is written in segmented blobs.