I'm currently on my first project involving a graph database . Dgraph coincidentally, and I somewhat like the product. But this is a horrible article that woul

I'm currently on my first project involving a graph database . Dgraph coincidentally, and I somewhat like the product. But this is a horrible article that would immediately leave a bad taste in my mouth if I were researching the product. It boils down to a shallow dismissal of relational databases that does not have much more substance than "Relational dbs are old and bad! Graphs are awesome because relations and queries!". Graph databases are often immature, don't enforce schemas, have little tooling, poorly understood or hard to tune performance characteristics, are somewhat messy when it comes to query languages (OpenCipher? weird GraphQL dialect? homegrown solution X?). The list goes on. A colleague who is an expert in this domain recommended to use (current) graph DBs only if you care more about the are relationships than the data. And probably only for data that you can lose, eg as a secondary storage. Criticizing the relative awkwardness of relations in relational DBs is valid, and has both historical and practical reasons. But the author wrote it himself: relational DBs are the first choice for developers. Not by accident, or because the internet told me to. But because they are excellent, mature, well understood, versatile products that can handle most of a regular applications requirements very well. No, you should not throw away every database and write all your future applications with DGraph. You may investigate if a graph database fits your specific use case, if the product is mature enough to rely on it, and if the added complexity (from devs to ops) is worth it. Vendors should promote the strength of their products, but also be clear about when it might not be a good fit. This kind of writing does not inspire trust in the quality of DGraph, rather the opposite.