Thomas HansenDisclaimer; I am the CEO of Aista, so obviously it’s impossible for me to give a 100% perfectly neutral comparison of these different stacks, considering that we look at Supabase and Hasura as our primary competitors. I will still try to provide a comparison, as neutrally as it is possible for me to do, without any bias, if that’s possible. However, realise that this analysis is created by a competitor of Supabase and Hasura.
Hasura
Hasura is smaller than Supabase. According to their GitHub profile, they have 28,124 stargazers as of today. Still they dwarf Aista’s GitHub profile in size with only 683 stargazers as of today. According to my knowledge Hasura is in round C of their VC investments, with the total amount of funding being between 100 million dollars and 200 million dollars in total.
Hasura currently supports the following databases; PostgreSQL, Microsoft SQL Server, Amazon Aurora, Google BigQuery, and YugabyteDB. According to their website they are working on support for; Oracle, MongoDB, MySQL, Elastic, Snowflake, CockroachDB, Athena, and SQLite. The fact that they’re implementing support for SQLite, implies they are looking towards hosting your database in the future, due to that SQLite is a file based database, without any networking. I don’t believe Hasura is currently able to give you a database, but I might be wrong here.
Hasura is exclusively delivering GraphQL gateways as far as I know, and they are basically a “gateway” to your own database. This implies that Hasura does not give you a full product, but rather you have to have an existing database from before, and Hasura only simplifies access to your existing data by providing you with a “GraphQL gateway” towards your own database. This implies you have to expose your database to the edge, allowing Hasura’s servers to gain access to your database somehow, which might result in both a whole range of new security issues, in addition to additional latency. The latter is especially true if Hasura’s servers and your database server is separated by a large physical distance. Depending upon how many data centres Hasura have, and / or how smart they are in regards to load balancing requests transparently according to the distance to your database, this might result in even the simplest of database retrieval operations requiring 1 second or more, when it should be easily retrieved in some few hundred milliseconds. In addition, Hasura can never deliver data faster than your database can return it. This comes in addition to latency issues due to distance between your database and Hasura’s servers. This architecture also for obvious reasons significantly increase the attack surface of our end product, since you now have a database exposed to the edge, and unless you really know what you’re doing here, you’ve opened up your database server for a whole new range of attack possibilities.
For the record, the latter is also true for Aista, but at least we have a “hosted database option” here, and so does Supabase.
There are of course multiple opinions about GraphQL – However, most of the concerns about GraphQL is that at least the way GraphQL is being used by Hasura, it probably results in opening up a whole range of security holes, in addition to that it moves the business logic parts from your server to your client frontend code. Having business logic on the client is for most of us considered an “anti-pattern.” Whether or not you think this is fine or not, is personal. However, the general consensus here amongst developers seems to be that the more experienced a developer becomes, the less likely he or she becomes to implementing business logic on the client, due to that he or she considers it an “anti-pattern”. When the client is generating its own GraphQL queries to extract data from your database, all business logic ends up on the client.
Having business logic on the client is a very, very, very bad thing!
If you are accessing Hasura’s servers directly from your frontend client code by passing in generated GraphQL snippets, this implies that everything required to build your application is moved from the backend API parts, and into the frontend client side code. Even ignoring issues such as “business logic injection attacks” (if that’s even a word), this simply moves the problem. You’ve solved nothing, you’ve just moved the burden of implementing your app from your backend to your frontend. You have arguably saved nothing. What you have achieved though, is the ability to write your app in one language. If all you know is one language, this might be a value proposition too tempting to resist of course. I suspect a huge amount of Hasura’s users today are junior developers, with zero knowledge about architecture and great designs, and that when they come out into the “real world”, their current methods of creating applications will be brushed aside as “toys for kids” ...
If you’re developing internal backend administration applications though, the above concerns are less important. For anything exposed to the edge of the internet though, allowing users to generate their own GraphQL queries and transmitting these to Hasura, this becomes a major problem – Due to that the client can at least in theory construct his or her own “business logic” and transmit these to Hasura to modify your data in unpredictable ways. This is a whole new security threat we don’t even have a word for because we’ve never even considered exposing such functionality historically for obvious reasons. If I’d have a go at coining a phrase for it, I’d name it ...
Business Logic Injection Attacks
Notice, Hasura is obviously painfully aware of their own shortcomings related to business logic, since one of their FAQ questions is; Where do I put business logic? As to their answers to this question, I’m not even sure if I want to comment on it. I’ll let their own answers do the commenting for me here. If you’re not technically savvy yourself, I suggest you find your senior developer and ask him; “Would you put business logic in stored procedures or event triggers?” I suspect your senior developer’s reaction will be all the understanding you’ll ever need.
Hasura's business logic answers
- Event triggers
- 3rd party REST APIs
- GraphQL APIs
- Stored Procedures and Database Functions
Notice – GitHub is now removing all GraphQL support from their infrastructure. Obviously GraphQL was a “bad experience” for GitHub. We have to assume the largest code repository service provider on the planet knows a thing or two about GraphQL that most of us have still to catch up on.
Supabase
In only 2 years Supabase has dwarfed Hasura. In its existence it has achieved 39.400 stargazers at GitHub. Supabase is built on an entirely different technology. However, Supabase seems to have GraphQL initiatives in the making, and might deliver GraphQL later since it’s currently a BETA product they deliver. However, their primary product today is based upon PostgREST. PostgREST is a thin layer similar to OData that sits on top of your web server allowing you to transmit basic queries that are executed towards your database. It suffers from the same “business logic injection attack” problems as GraphQL, and simply moves the burden of implementing business logic to the client, solving few problems really.
Supabase are marketing themselves as “The open source alternative to Firebase”. However, technically the platforms couldn’t be further apart, although for practical concerns they have similar functionality. Supabase too have gathered some slightly more than 100 million dollars in VC funds, and are currently in round B of their funding.
Supabase contrary to Hasura is a more “complete” solution, since they do provide you with file storage, and a PostgreSQL database. I am not entirely sure if Hasura provides you with a database, but I couldn’t find any information on their website in regards to this – So I suspect Hasura only works as a “gateway” to your own existing database.
Because Supabase is more “complete” you can use Supabase “out of the box” and immediately start creating your frontend code after having designed your database. This is not that easy with Hasura, since you need an existing database, and existing authentication endpoints, etc. On the simplicity scale, I suspect most developers would experience Supabase as the superior product, since they can instantly start creating frontend code – Where as with Hasura, you need to have an existing database and an authentication server before you can even start using their product. Supabase also provides authentication out of the box, allowing you to ignore everything that’s backend code, exclusively focusing on frontend. For obvious reasons this is probably a very tempting value proposition to junior developers and frontend developers only having experience with JavaScript or frontend platforms such as the iOS SDK, etc. Supabase is also much less expensive than Hasura, which begs the question if they can keep on delivering at these prices, or if they have to increase their prices as they run out of VC money.
My question to Supabase though, is arguably taken from Hasura’s FAQ, and basically sums up the problems you will be facing if you choose Supabase, and it is as follows ...
Where do I put business logic?
If you don’t understand the problem related to business logic, have a key account manager at Supabase explain to you how you’d go about with sending an email as an endpoint is being invoked. This is a ridiculously simple “business logic use case”, and I suspect you can’t even do it in Supabase without invoking some 3rd party API, such as SendGrid from your client side frontend code. Notice, sending an email from your client side frontend code is a very, very, very bad thing! If you don’t understand why, let me enlighten you ...
Postman + credentials to SMTP server + script kiddie with access to API == 40,000 emails sent per second to some “whatever email address”
Are you beginning to see the problem here …?
Edit - Read the comment further down, where one of the co-founders of Supabase answered my question by showing how "edge functions" can solve the problem.
AISTA
Aista don’t provide any “query languages”, neither GraphQL, PostgREST, nor OData. Instead, we generate code automatically in your backend. This creates a “strongly typed” web API, exposing meta data to clients wanting to automatically generate frontend code. An example of an app that was 100% automatically built using this process can be found below.
Ignoring the fact that we solve the business logic problem, by allowing you to implement your own business logic on the server – Even imagining some GraphQL, PostgREST, or OData endpoint being able to generate something such as the above, is simply impossible. The reasons are because a “strongly type” web API exposes meta information about your database. Something that’s completely lost as you have a dynamic endpoint accepting some “query language”. This is true both for PostgREST queries and GraphQL queries.
The disadvantage with us compared to Hasura and Supabase, is that you have to learn a new programming language called Hyperlambda. This might be a larger initial investment for you mentally, since learning a new programming language is hard – However, we have done it as easy as we can for you by creating a Free Hyperlambda Course where you should be able to at least in theory learn Hyperlambda in 5 to 10 hours, depending upon how much software development theory you understand from before.
However, where Supabase and Hasura are “shiny toys for JavaScript script kids”, we allow you to create complete apps, with complex business logic, integrations towards 3rd parties, send emails securely (pun!), and whatever you want to do. The initial mental investment you have to do with Aista is slightly larger, unless all you want is a CRUD frontend of course – However, once the initial investment has been done, you can create things you can’t even imagine doing with Supabase and Hasura – At least not without creating your entire business logic in your frontend – Which I assume you at this point understand is a very, very, very bad idea!
Conclusion
Yet again, I am the CEO and founder of Aista, so obviously I am biased, and you will need to make up your own opinion in the end. However, when I’m thinking of that both Supabase and Hasura was able to get hundreds of millions of dollars in VC funding, and I and most other senior software developers cannot even take their value proposition seriously, and they have close to zero intellectual property due to being thin abstractions on top of open source products they do not own themselves, and everybody can download and install on their own VPS in minutes, and that there are …
It becomes increasingly difficult for me to even take them seriously. In fact, I told my partner several months ago when we discussed Hasura over a dinner the following.
If you want me to create a Hasura copycat company, I would need 3 devs and 3 weeks, at which point I’d be able to technically completely replace their entire value proposition ...
The same is of course true with Supabase. These companies aren’t software development companies, they are something else. I think I should avoid enlightening you with my theories in these regards though, due to me after all being biased the way I am. However, it is impossible for me to take them seriously, at least from a technical perspective … 😉
They are both very good at marketing though, and they have nice websites – At least that counts for something … 🙂
If you disagree with me, please explain in a comment how I'd go about sending an email as a Supabase or Hasura endpoint is being invoked - FROM the server, without having to expose my SMTP credentials to my frontend in any ways ...
