Recently I had some related ideas, although from a completely different background. Here is what I would have done differently:<p>1) Implement other storages. Although databases are a natural part of web applications, a direct storage in files and/or directories may be justified. Also, for most applications the full dataset fits easily in the RAM on modern systems.<p>2) Keep full history. Or provide for this possibility at least. Adding history features to classic database models becomes cumbersome quickly, but for a simple schema it may be provided directly by the framework. This provides for a great audit log if something went wrong. Probably to be disabled if really unwanted and/or storage size is an issue.<p>Regarding the different background: Although most people want graph databases if they don't want to enforce a certain schema, my desire is the exact opposite. I want more constraints, data integrity as much as possible. I want more than can be easily reached even in PostgreSQL with user-defined functions, such as constraints across foreign keys. So a separate checker is needed, and I believe graph structure with plain links provide a good, simple base to define a constraints framework upon it.