Comparing data APIs on Hasura to data APIs on Firebase

Hasura and Firebase both offer database APIs. In this post, we compare the pros and cons of each.

Hasura and Firebase come with Backend as a Service (BaaS) APIs that help you develop your application faster. A key component of any BaaS is instant APIs over a database — once you define your database schema, you should get data APIs instantly.

Hasura and Firebase both offer APIs over a database. Differences in the data APIs offered by Hasura and Firebase arise because of two fundamental reasons:

  1. Hasura offers data APIs on top of Postgres, while Firebase offers data APIs on top of a proprietary database.
  2. Firebase was originally designed exclusively as a realtime database, before developing to offer broader functionality.

Below, we talk briefly about some of the key differences. We will restrict ourselves to cases where Firebase is being used as a generic database (and not for its realtime functionality — Firebase was originally designed and is especially suited for realtime apps).


With Hasura, you have the full power of SQL, including the ability to make bulk queries. Once an application is in production, you will need to write complex queries, especially for the purpose of Analytics or Business Intelligence.

With Firebase, you are restricted to basic CRUD queries. This is okay for rapid prototyping, but does not lend itself to a production app.

Schema Management and Migrations

This is probably one of the biggest gripes power users have with Firebase (see point 6 here). On Firebase, you can only change data from the client side. This means you have to write a script to perform a schema evolution (which is error prone and risky if not performed in a transaction, or in sets of transactions) or handle the schema evolution in the app code itself.

On Hasura,

  1. Migration files are automatically created as you create/alter tables.
  2. Schema and data migrations can be specified declaratively in yaml files.

(More here).

This is similar to the the natural developer workflow of taking changes in dev and then applying them in staging/production environments.

Data modelling

Thanks to the use of Postgres, Hasura supports relational modelling and JSON types. Relational modelling makes it easy to model data with lots of inherent relationships without duplicating data or worrying about handling updates, while JSON types give you schemaless flexibility when you need it.

It is harder to model relationships between independent data models with Firebase’s proprietary database (originally a realtime database). If you made a mistake early on in your modelling, migrating and changing to a new data model is hard.


  1. Firebase permissions can only capture rules based on the data within the current ‘path’ (node). On Hasura, you can specify granular permissions based on the user-id in a row or based on relationships with other tables.
  2. Postgres has one of the deepest, most experienced communities going around, while the Firebase community is new and rather thinly populated (particularly when it comes to experts). It is much easier to get help for queries related to Postgres.

We have laid out some of the ways in which data APIs on Hasura differ from data APIs on Firebase. Let us know your thoughts in the comments below!

Hasura is an open-source engine that gives you realtime GraphQL APIs on new or existing Postgres databases, with built-in support for stitching custom GraphQL APIs and triggering webhooks on database changes.



The Hasura GraphQL Engine gives you realtime, high performance GraphQL on any Postgres app. Now supports event triggers for use with serverless.

Read More