Prisma is a database toolkit that's used by application developers to develop server-side applications in Node.js and TypeScript (e.g. REST APIs, microservices, gRPC calls, GraphQL APIs, ..., anything that talks to a database). The main tool Prisma Client is a query builder that's used to programmatically send queries to a database from Node.js/TS.
Hasura is a "GraphQL-as-a-Service" provider that generates a GraphQL API for your database. This GraphQL API is typically accessed by frontend developers.
That setup can be great when your application doesn't require a lot of business logic and the CRUD capabilities that are exposed in the GraphQL API fit your needs (though I believe you can add business logic in Hasura by integrating serverless functions).
With Prisma, you're still in full control of your own backend application and can choose whatever tech stack you like for developing it (as long as it's Node.js-based, though Prisma Client will be in available in more languages the future)!
By the way, we also love GraphQL. We're currently brewing a new "GraphQL application framework" that can be used on top of Prisma. That way it will be possible to auto-generate resolvers for Prisma models to reduce the boilerplate you need to write, while still keeping the full control of your GraphQL schema.
I want to point out a defining characteristic between Hasura and Prisma:
While Hasura does work to auto-generate a GraphQL API from an existing database, it also has a web console that lets you build your database models and relationships, plus permission logic and authorization point-and-click.
Custom business-logic outside of the CRUD it generates is done by writing HTTP endpoints that you can wrap as "Actions", which it generates GraphQL types and resolvers for as part of it's schema. IE, you will want to define an API endpoint for login/signup, and declare these as "Actions", which you can then query from Hasura's schema.
An SDK/toolkit can be auto-generated from the GraphQL schema Hasura produces using graphql-code-generator, giving you strongly-typed query/mutation/subscription components in your desired frontend framework (IE React/Vue/Angular + Apollo/urql etc.)
Scheduled tasks/cronjob functionality is under development as well.
Prisma gives you a "finer grained" set of tools to "build" an application with, where Hasura kind of just hands you the whole thing (though in an opinionated fashion).
Hasura can run as a Backend as a Service, ie standalone with a direct connection to your database and nothing else. For custom queries you can use Hasura Actions.
Prisma and others like Apollo server are libraries you need to add to your Node app, ie not standalone. They give you more customization because you control the entire server and what functions to run.
The difference is just in how custom you want it and how much setup you don't want to do.
Prisma is a database toolkit that's used by application developers to develop server-side applications in Node.js and TypeScript (e.g. REST APIs, microservices, gRPC calls, GraphQL APIs, ..., anything that talks to a database). The main tool Prisma Client is a query builder that's used to programmatically send queries to a database from Node.js/TS.
Hasura is a "GraphQL-as-a-Service" provider that generates a GraphQL API for your database. This GraphQL API is typically accessed by frontend developers. That setup can be great when your application doesn't require a lot of business logic and the CRUD capabilities that are exposed in the GraphQL API fit your needs (though I believe you can add business logic in Hasura by integrating serverless functions).
With Prisma, you're still in full control of your own backend application and can choose whatever tech stack you like for developing it (as long as it's Node.js-based, though Prisma Client will be in available in more languages the future)!
By the way, we also love GraphQL. We're currently brewing a new "GraphQL application framework" that can be used on top of Prisma. That way it will be possible to auto-generate resolvers for Prisma models to reduce the boilerplate you need to write, while still keeping the full control of your GraphQL schema.
You can learn more about this here: https://www.nexusjs.org/#/