Hasura engg. here. No offence taken! :) Hasura is indeed kind of what you described. The warning on the UI is mostly for non power-users who probably don't ha

Hasura engg. here. No offence taken! :) Hasura is indeed kind of what you described. The warning on the UI is mostly for non power-users who probably don't have a good db migration kind of practice. Underneath, the Hasura data API stores its minimal metadata within Postgres itself. That means that you can always use Postgres directly, and your migration tool works exactly the way it should. Whenever your schema migrations affect a data API, you need to ensure a metadata update for the Data API as well. We're going to be publishing examples of how DB migrations look using just a raw SQL setup, and an alembic setup! The speed increase for the Data APIs is because of a few reasons: 1) Efficient serialization/deserialization of the JSON queries and responses (https://hackage.haskell.org/package/aeson https://hackage.haskell.org/package/aeson) 2) Prepared statements 3) JSON aggregations done within Postgres (not generating the JSON) 4) Every client API call needs to be authenticated. The authentication is done by a efficient middleware written inside nginx with redis as the session store. The data API layer, then just does the authorization (this user-id can access this row).