You don't. Hasura (and Postgraphile and PostgREST) employ in-database modeling tools called views. Views provide the same modeling abstractions that ORMs provide.
https://www.postgresql.org/docs/12/sql-createview.html
A view is a canned query with a name, and when you get down to it, all an ORM is doing is producing, usually poorly, a query from a named abstraction. Same thing. So why have two pieces in two languages when you can have one?
> Isn't the point of GraphQL to decouple your interface (who should not break) from your backend implementation details?
Views provide the same or better decoupling. They database is aware of them, they are type checked, you can't even make a view that references an unknown column, for example.
Either it is an internal service, only consumed by your own products, and then it's fine. Or you have an API gateway to control who and how your services are queried.
The API Gateway is your interface who should not break. Your services communicating with your database (through Prisma, Hasura, any ORM, ...) can and will break.
When you base your GraphQL schema on your database schema for your internal services, you get rid of one long and annoying step of putting glue everywhere. This is especially true in a microservice architecture, and even more in the corporate world where you are expected to produce code quickly.
Isn't the point of GraphQL to decouple your interface (who should not break) from your backend implementation details?