Databases aren't simply persistence layers, they also encompass querying which implicitly couples your application to them. The simplest query model is the key value store, which itself is a form of coupling, but it's quite limited in the operations it can support with high performance.

GraphQL is similarly not a transport layer. The transport layer for GraphQL is HTTP. GraphQL is a query language. To use it with a particular database you need to transpile GraphQL to the query language supported by your database. Usually this is done in an unprincipled manner with ad-hoc code. In other cases it's done more globally and formally, as I assume Hasura is trying to do.

I agree – but that doesn't actually challenge my argument. I would be reluctant to use this due to the very tight coupling to GraphQL and Postgres.

Unless – of course – you simply want something working quickly that does not need to be maintained or kept alive for a long time.

If you're not going to couple any business logic to the persistence layer, then what the hell is the point of using a RDBMS?

Your reply suggests you either couple everything or nothing. It’s more nuanced than that. Everything is a trade off. With that said, it looks like this library will position itself in the center of your architecture — and I would be very hesitant to do that.

Of course anyone should be hesitant to over-model the business domain in any part of the application including the database, but the entire reason of existence of the RDBMS is to maintain consistency with something, and if that something isn't the business domain, then what good does it do?

I don't know where over-modeling fits in the argument. Business logic in an isolated part of an application is likely to age better than something that is intertwined with a database or other external dependencies.

Data consistency with concurrency (transactions).

What is your data supposed to be consistent with, then?