Dgraph, GraphQL, Schemas, & CRUD – Ardan Labs

I have not used a GraphQL database, but one of the things I fear about designing a relational database is mentioned in the article:

>"Relational databases are very rigid so you need to really make sure you understand your data upfront. Changing the database is a big effort..." (emphasis is mine)

Given how often requirements change in a business, it seems impossible to anticipate all future requirements at the outset of designing a database. Is it true that changing a (relational) database schema is a big effort? Is this a strong case for GraphQL?

1. The data at rest (in your relational database) - database migrations are the solution to this problem, in one way or another. Migrations are well understood, and are not hard - just tricky to get right depending on the complexity of the change. 2. Rules about how to turn that persisted data into something you can reason about at runtime (aka hydration logic) 3. Rules about how to change data from one form or another due to business rules (aka business logic)

If your database is an implementation detail and not the heart of how you reason about your system, then the difficulty in making the migration from one form of data at rest to another should be easier. If you rely on your database for storage and business logic, then you may have a more difficult time.

I'd argue relational DBs get way more credit than they're worth. And it is indeed tricky to make them work across different data models -- that's by now an established fact across big SV companies. Restricting direct access to rigid RDBMs and making data modeling easier via graphs is why Facebook Tao, Dropbox Edgestore, Airbnb Knowledge Graph and so on exist. See my post [1].

I'll give you a simple example. Consider, movies and directors. If you started with the fact that each movie has exactly one director, you'd design exactly one table, with a director column.

Later, if you realize that each movie can have multiple directors, you can't just alter that table. You need two new tables -- one for directors, and another one to connect movies to directors. That's not simple, that's a big change which requires a bunch of work.

Doing this in graphs is simple. Adding a bunch more outward relationships is simple. Data modeling, in general, is way simpler in graphs than in RDBMs.

Mongo and such came out of the Bigtable era. Cockroach and Dgraph are coming out of the Spanner era -- where it's not only about horizontal scalability, but also about strong data integrity and distributed ACID transactions.

[1]: https://dgraph.io/blog/post/how-dgraph-labs-raised-series-a/

I feel like many of these criticisms of RDBMS come from a perspective of not working with a great database migrations system.

I've made changes like this (one-to-many switched for many-to-many) using Django migrations many times over, and I find it easy. But that's because I've built up the experience with the tooling over time.

Learning migration tooling in this way feels like a much smaller lift to me than entirely switching to a graph database.

(I'm a big fan of Dgraph, but I've not yet found the right project to apply it. I'm not interested in it as a replacement for RDBMS, I want to use it to solve graph problems that are genuinely painful with a relational database. Easier schema changes aren't that for me.)

The hard part is updating all the application code that was written assuming that a movie has one director. I'm not super familiar with graph DBs, but I don't see how they could possibly help with that.