A year after we chose to go with PostGraphile over Hasura in production
- Hasura had Apple silicone compatibility issues for local development
- executable npm package vs complex dockerized black box
- Express.js middleware or plugin approach vs. Webhook approach
- management UI
We needed a GraphQL API in front of our Postgres database with a few criteria:
- Quick and easy to setup and manage. Just give us CRUD ability for the required tables based on the schema of the database without any hassle
- Granular control over authentication ie.: certain group of users are restricted only to a subset of the data inside the database
- Subscriptions so users can see live data inside the UI
Usually with requirements like the ones mentioned above our go to database would be Firestore but this time we had to use Postgres for other reasons. (I didn’t really mind this because Postgres is my favourite database.) We created a POC for both PostGraphile and Hasura and made a decision based on our experiences. Now after more than a year we still think that going with Posgraphile was a good choice. Don’t get me wrong Hasura is a great tool and might be a good fit four your project.
- Management UI is really nice. It out of the box gives a DB management tool similar to pgAdmin. It is a well designed web UI with a lot of features, I’d say almost all features that a developer might need for managing a DB and a GraphQL server. It’s easy to manage subscriptions, row level security, GraphQL query resolvers etc. from Hasura’s UI. I’m not advocating it, but even non-developers can also use it.
- Logs and errors inside the management UI
- Good documentation
- Large community
- When we tested it there was no support for M1 Macs. The official Hasura docker image wasn’t working on M1 Macs. So we had a couple of options to mitigate it and non of the felt very good. Use a non-official docker image for half of our time and risk that some difference will only show up in our dev environment. Don’t use a local environment for development. Compile the Hasura ourselfs for M1.
- Under the hood Hasura is very complex. Hasura is shipped as a payed service or a docker image for self hosting. In theory you can fork Hasura and edit it’s sources, but the codebase consists of TypeScript, Haskell and Go built with a Makefile system. Their design philosophy is the follwing. They support most of the industry standards like Postgres row-level security out of the box. But if you want custom logic inside Hasura let’s say for some special protocol to handle an edge case with user authorisation then you can attach a webhook inside the UI and Hasura will comply to whatever your service answers.
- Lightweight. It’s available as a standalone executable
npm package, Express.js middleware and as a Docker image as well
- It’s made only for Postgres and it knows Postgres well
- Easier integration with application monitoring services like New Relic or Sentry.
- Worse documentation than Hasura
- Code only, there is no UI. So if you want some web based DB management tool you have to set-up something like pgAdmin
- Smaller community
So we wighted what’s important to us and as the title suggests we went with PostGraphile. I’m sure some of you reading this article would choose Hasura based on the same pros and cons. For us the Hasura UI was really tempting but the simplicity of PostGraphile won at the end of the day.
Need more assistance?
We can help you in finding the most adequate solution for your issue!
Book an interactive video consultation with us. Get an interactive one on one or team session with our experienced developers.
Educate your team
We can hold on-site (in the EU) or online trainings.
We can help your team to learn new technologies or master certain "grey area" aspects of already used tools.
Hire us to build your product
Hire an individual or a team of developers to solve build your product.
We can integrate into an ongoing project, or kick off and layout the foundations of an entirely new solution.