The reason: SQL, even PostgreSQL with userdefined functions, is not strict enough for me. As soon as a consistency rule involves multiple tables, things. There are some nice SQL tricks with duplicating columns across those tables, whose consistency is ensured by putting them as additional columns into foreign keys. But for my taste this is too much trickery, and this approach has its limits as well.
I hope that one day the Graph databases will be combined with strict schemas that go far beyond XML schema, JSON schema and SQL database constraints. Also I hope that expressing those constraints should be easier, not harder, to read when applied to a graph database.
The graph database model is driven largely by a desire for better navigational convenience at the expense of weaker schemas compared to RDBMS models. So, while you can wish for anything, I don't see that that's likely to happen. RDBMSs start ahead of graph databases when it comes to stronger schemas, and there's no reason that any stronger schema techniques would be more applicable to graph databases than to RDBMSs.
I agree that today's graph databases are meant to be used for weaker schemas, I believe that they are conceptually a better fit for strict schemas than relational databases are.
But probably we need a third term for those ultra-strict databases. From the "look and feel", this new type would almost certainly look more similar to a graph db than a relational db.
You may be interested in (soon to be released) EdgeDB: http://edgedb.com/
(Disclaimer: I'm one of the devs behind it).
Alas, there is no RSS/Atom feed. If that site had one, I would have thrown it into my RSS reader. (I hesitate to throw my email address into such sites, sorry.)
BTW, will there be an Open Source version of the DB?
As for emails - we won't disclose them to anyone, or fire emails more often than 1 in 3-4 weeks.