Shipping fast

With so many new tools there are far more ways to build stuff now than ever, but the tools you choose could make the difference between taking months to ship a product or taking only days.

For a long time devs would just write backends by hand, but this was tedious and time-consuming. Now we have services like Firebase, Hasura, Nhost, and Supabase that speed up development by taking care of backend features like databases, API endpoints, user authentication, and storage.

Firebase was one of the first solutions but it was proprietary software, a huge turnoff for many devs. Then came Hasura in 2017, an open-source solution that enabled a low-code GraphQL interface to access your PostgreSQL database along with your other standard Postgres features. Nhost came shortly after, providing Hasura as a service along with other backend features like authentication and storage.

And then in 2020 came Supabase, positioned as an open-source alternative to Firebase. It’s hard not to hear about how great Supabase is, but for the past few years I’ve avoided it because I was just so happy with Hasura and Nhost.

What makes Hasura so Good?

Automatic GraphQL on all your data

GraphQL promised a simpler developer experience where you could fetch the exact data you needed, but if you’ve ever written your own GraphQL resolvers you know this is only a half-truth. Sure, it’s arguably easier for frontend dev work, but now every column of every table is essentially an API endpoint you have to write a resolver for. Many times it was easier to just build normal REST APIs.

Hasura fixed all of this.

It provided instant CRUD-based resolvers for queries and mutations, with filters and operators, on every table and column, along with access to role-based authorization.

Point and Click UI

It’s so refreshing to be able to use well-designed abstractions that automate boring tasks while still providing the option to drop down to code for flexibility and customizability, and that’s what Hasura provides.

Anything from creating tables to adding auth policies and custom SQL, to constructing queries is just a click away.

It opens up access to data so much more because the barrier of entry is so much lower, you no longer need to think in code, you just click what you want, as if you were online shopping in your database.

Separate Service

One of my biggest gripes with GraphQL was how much crap you needed to add just to use it. Large libraries to make graphql requests graphql-ify your data.

Hasura sits in between your server and database and requires no glue code or extra libraries. It’s agnostic in what you use in your code as it only exposes an HTTP endpoint to connect to.

Why change?

For one, a large part of Hasura’s focus over the past couple of years has been to support more databases, but these updates provided little to no value for the average developer. Along with their recent pricing changes, it seems they’re focusing a lot more on their enterprise clients and that worries me for the future of the open-sourced community edition of Hasura.

And two, Nhost, perhaps the best provider for Hasura as a service, with auth and storage included, recently changed their free tier pricing from allowing unlimited active free projects to one active free project. I like my free stuff, and Supabase offers 2 free active projects, that’s 2x more than 1!

But also because despite being a separate entity, Nhost is inherently tied to Hasura and I don’t like the direction Hasura is going in.

Migrating to Supabase

Ever since its launch, Supabase has been crushing it with new features, documentation, marketing, and support, even launching support for new hotnesses like pg_vector and text embeddings that enable new AI-related workflows.

For the most part, the development flow is similar.

Things like creating tables and updating columns can be done with a point-and-click UI. The main differences I found were:

Writing SQL

Things like accessing data within your DB and setting auth policies require actual code, whether with SQL or through their client library. It’s much easier to build queries with button clicks in Hasura than it is through writing code with Supabase.

Migrations are manual

In Hasura, migration files are automatically written after every database update. If you use Nhost for Hasura then migrations are automatically deployed when your specified production branch is pushed. It’s a huge timesaver.

With Supabase, migrations need to be done manually through their CLI, though they do have a diffing command that comes in handy.

GraphQL support

Though Supabase has released support for GraphQL it’s still relatively new and doesn’t have the same level of support for many features in GraphQL as Hasura, some of which include:

• Support for nested mutations
• Querying by primary key
• Certain filters
• Better GraphQL editor with query builder and recent history in sidebar

Verdict

In terms of productivity, I’d have to go with Hasura, specifically with Nhost. The low-code UI Hasura provides, combined with Nhost’s supporting features and infrastructure, are just too good. I don’t have to think about code when interacting with my DB. It’s point-and-click to build tables, auth policies, queries, and mutations, all while maintaining the ability to drop down to code if needed.

Supabase is still a great choice and I’ll be trying it out for my next few projects.

Besides the better documentation, more active community, and more generous free tier, I think Supabase is better aligned in the long term for the average developer because of Hasura’s focus on enterprise clients and Nhost’s dependency on Hasura. Also, if Supabase keeps up their pace it won’t be long before they close the gaps they have between them and Hasura and Nhost.

Not having access to Hasura’s UI is quite a loss but SQL is a powerful language that’s not going anywhere and this makes for a good excuse to get more proficient in it. Plus, with Supabase’s recently added AI docs helper, writing SQL is only going to get easier.

Other than that, Supabase offers the same features I care about and I think it’s a good idea to explore new options to keep from vendor dependency.