Neo4j, at least as of about a year ago, was seriously lacking in constraints and guarantees to use it as a database of record. Performance-wise, it's fundamentally built to perform well at a small set of specific graph operations, while more normal DB operations or even doing graph things plus fairly ordinary data fetching with those graphs was, necessarily, anywhere from so-so to terrible, as far as performance. Looking at how N4j stores its data is enlightening. It's also a huge memory hog (Java, plus leaning hard on cached data in memory to keep performance tolerable due to the aforementioned trade-offs).

Didn't stop N4j's marketing folks from trying to sell it as suitable for basically any purpose. Gotta get that unicorn growth. Very early-MongoDB in that regard. "No, really, it's suitable for whatever you're doing—probably the best for it, in fact! Uh, what is it you're doing, again?"

That one, at least, is best suited to assisting some other, primary DB, for a certain narrow set of tasks.