If you are using Postgres and GraphQL, then chances are that you have heard about Hasura. Since Space Cloud also offers GraphQL APIs on top of Postgres, many people ask us how Space Cloud differs from Hasura.

This blog post is intended to answer all your curiosity to the best of my knowledge. This post is more of a qualitative analysis as I am going into the philosophy and the possibilities rather than just comparing features. Please feel free to reach out to me on Twitter or Discord (@HeyItsJs) if you have any questions or feedback.

Note: Even if you’re an Hasura advocate, you would love this post!😃

What is Hasura?

As per its Github page, Hasura GraphQL Engine is a blazing-fast GraphQL server that gives you instant, realtime GraphQL APIs over Postgres, with webhook triggers on database events, and remote schemas for business logic.

And this is entirely correct. It provides instant GraphQL APIs on top of new or existing Postgres within minutes. Setting it up is easy. It comes with an in-built data and GraphiQL explorer and can get you off the ground with GraphQL in no time.

Here’s how Hasura fits in your architecture:

Hasura architecture

What is Space Cloud?

To keep things simple,

Space Cloud is a cloud-native backend server that provides instant, realtime APIs on any database, with event triggers and unified APIs for your custom business logic.

Even though Postgres is the most advanced open-source database out there, any modern mobile or web application requires a lot more than it. Storing files, authenticating users, and writing custom business logic are all a crucial part of modern applications. While Hasura does a great job at automating the GraphQL APIs for Postgres, you still have to write/integrate the rest on your own.

This is precisely where Space Cloud shines. It intends to be a unified API layer for all your requirements. (database, file storage, authentication, custom business logic) It aims at simplifying your entire app development journey rather than just the CRUD operations.

Here’s how Space Cloud fits in your architecture:

Space Cloud architecture

Note: You can also consume the REST APIs of Space Cloud if you are more comfortable using REST.

Depth vs Breadth

A few months back, when I took the responsibility of a Product Manager for Space Cloud, I was confronted by a serious question - How to decide which features to add next to Space Cloud. Should we go for adding more modules or should we enrich the existing ones?

As usual, I looked up to our Founder - Noorain (YourTechBud as he calls himself😅) and I still recall what he said so clearly:

Let’s focus on the breadth and show what’s possible and trust our community to guide us through the depth

And that has been the guiding principle of our product development since then!

So while Hasura may support that advanced Postgres type you might require, adding it to Space Cloud wouldn’t take a day or two. However for Hasura to add support for let’s say a MongoDB might take ages because of its tight coupling with Postgres. On the other hand, adding new databases to Space Cloud is very easy because of the way we have built it.

It’s our strategy to add features on demand when requested by our community. If you feel something is missing in Space Cloud, create a ticket for it in our Github repo, and help us build it. Or even better, join our Discord community and together we can shape the future of Space Cloud and app development space!

Invoking custom business logic

No matter whatever APIs any tool provides, you end up writing your custom code on many occasions since not everything can be automated.

With Hasura, you have to write your custom logic in the form of a GraphQL service and add it as a remote schema to Hasura. Since GraphQL libraries are available in most languages, Hasura is pretty much extensible.

However, GraphQL is pretty new, and even though we all love using GraphQL from our front-end, it’s relatively difficult to write a GraphQL backend. Most of us are comfortable writing REST services since that’s what we have been doing for decades. And that’s the reason why Space Cloud allows you to write your custom business logic in the form of simple REST services.

The cool thing about Space Cloud is that you can trigger your REST services via the GraphQL API of Space Cloud:

Remote Services

Thus Space Cloud provides extensibility at the ease of writing REST services. Interestingly with Space Cloud, you can migrate your existing REST services to GraphQL without changing any code.


Joins in Hasura are limited to tables in Postgres.

However, most modern applications require multiple task-specific databases. Since Space Cloud acts as a unified API layer for all your data sources, joins across data sources is a breeze. Following joins are supported in Space Cloud:

  • Joining tables in the same database
  • Joining tables in different databases (Cross-database joins)
  • Joining data from microservices
  • Joins across database and microservices

For example, you can join data from your Postgres, MongoDB and a remote REST service in a single GraphQL query using Space Cloud. This ability to provide unified joins across various data sources opens up infinite possibilities.


Hasura allows you to create Postgres tables via a simple form in their console. It also lets you run SQL queries directly from their console.

Space Cloud on the other hand, provides a GraphQL SDL driven schema similar to Prisma:

type author {
 id: ID! @primary
 name: String!

The best part about this schema SDL provided by Space Cloud is that it is declarative in nature. The bonus? You can merely update the schema to what it should look like, and Space Cloud performs the exact incremental operations required to bring your database schema to the desired one no matter what it’s current state is.

Another benefit you get with schema module in Space Cloud is that it’s consistent across databases. Which means you don’t have to learn database-specific statements as Space Cloud handles it for you.

Note: With Space Cloud you can even model your relational data on MongoDB the same way you would do it on Postgres.


The GraphQL schema SDL also serves the purpose of data validation in Space Cloud. Data validation happens at the application layer rather than the database layer. Thus, you get a schema validation layer even for your schemaless databases like MongoDB.

Note: The GraphQL layer of Space Cloud is completely schemaless, which means you can consume your databases from GraphQL even without mentioning a schema. Schema only serves the purpose of data validation and table creation/modification.


Space Cloud loads all its config (the databases to use, their schema, security rules) from a config file. You can version control this config file using Git or any other VCS. Since the database schema in Space Cloud is declarative, migration from DEV to PROD environments is as easy as pointing the new Space Cloud to the appropriate config file. Space Cloud automatically creates tables as necessary.

With Hasura, these migrations are more complicated. It requires you to install a CLI which generates migration files for your database schema as you go on creating tables through console. But these migration files are imperative rather than declarative. That means you have to apply the right migration files to be able to achieve the desired state.

Event Triggers

Event triggers are used to trigger your custom logic asynchronously based on some events. For example, you want to send out an email whenever a user signs up.

With Hasura, you can trigger your custom logic only on Postgres events.

But with Space Cloud, you get an eventing layer for your entire app. Not just you can trigger your business logic on database or file storage events, but you can also have trigger on your custom events. The eventing queue of Space Cloud is reliable, i.e. it has an auto-retry mechanism (configurable).

The best part about Space Cloud’s eventing queue is that you can even schedule events. Yes, you heard it right! Meaning if you want to send your email one day after a user has signed up, Space Cloud has got you covered. Pretty cool right?

Note: Hasura also has Actions (custom events) which is in preview at the time of writing.


Both Hasura and Space Cloud are great projects which help you save time and effort that goes into building your backend. And most importantly, both of them are open-source. So you don’t need to worry much while going forward with any of these. While Hasura focusses on being Postgres first, Space Cloud aims at simplifying the entire spectrum so that you have to write as less code as possible.

Space Cloud is an excellent fit for frontend developers who want to make a feature-rich app all by themselves. Take Space Cloud for a quick spin today and let us know how we can improve. Don’t forget to give it a star ⭐️ if you like it!