[Disclaimer: Work at Hasura] One small clarification about this point: "So, what you need to do to use Hasura is to first lay out all the tables in Postgres,

[Disclaimer: Work at Hasura] One small clarification about this point: "So, what you need to do to use Hasura is to first lay out all the tables in Postgres, and then map those table schemas to GraphQL schema. Any changes to the schema would then need to be applied first to the Postgres instance, and then brought back to Hasura" This is partially true (you need to define DB tables), but it leaves the sense that if you make DB schema changes, you need to run a second step for the GQL schema to reflect this. If you change existing tables, nothing has to be done. If you add a new table, you have to press the "track/track all" button to expose it via GQL. And if you made join-tables or new FK relationships, you need to press "track relationships". For the most part, Hasura is meant to just stay synced to your DB schema (database-first development). "You set the GraphQL schema directly. Any changes are done within the GraphQL schema itself, and the database figures out how to serve that best." This is where I'd say the approaches differ, Dgraph being GQL-Schema first and Hasura being Database-Schema first. Not to say that one is inherently better than the other, they're both entirely valid approaches and Dgraph is a solid product.