One problem with any such databases is that, because they are so useful, you end up making a great deal of use of them, and in particular code using them metast

One problem with any such databases is that, because they are so useful, you end up making a great deal of use of them, and in particular code using them metastasizes everywhere, and worse, schema gets hard-bound into all that code everywhere. Then one day you want to: - make significant and incompatible schema changes - move subsets of schema/data out to separate partitions / DBs - implement a merger - change DB / vendor and... you can't. All that code capturing the specific API, QL, and the schema (and metaschema!) is spread all over the place, and it's too much to change, and you can't do it in any sort of atomic manner. The change will take forever and will be very costly -- you might not even bother. You're stuck. Vendor lock-in, but more awful than usual. But what's so special about GraphQL? Active Directory has the same problem, really. It's just that AD -and all LDAP-based DBs like it- is kind of icky because the metaschema (particularly X.500 naming) is icky, so it hasn't metastasized as much. What's the solution? I would suggest that one has to build a proxy API to capture all direct uses of the DB and schema, and which presents a task-oriented interface to it (e.g., "add user to group", etc..). This way you can later rewrite just that very isolated and tested component. But the problem with that is that you have to bring forward a lot of the switching cost into the present, and that might be pointless cost if you end up never switching. I.e., there's no silver bullet.