My main use case for Hasura involves dealing with multiple source systems, where we had to create a bunch of repetitive backend work, leading to many APIs that needed to be built. Hasura made development easier because it was useful without wasting time building basic APIs over and over again; instead of creating the controller, service, repository, and DTOs manually, along with filtering and sorting, Hasura has made the work straightforward.

A quick specific example of a project where Hasura helped me save time is our auto-renewal system, which we built in a recent renewal job. Without Hasura, after processing, a backend would need to expose an API endpoint such as /renewals, requiring us to manually build the DTOs, maintain multiple endpoints, support frontend changes, and handle real-time updates separately using WebSockets. With Hasura, the work became straightforward; the .NET jobs update the database, and it automatically exposes the updated data with no need for backend changes, also aiding in the real-time dashboard updates.

The feature that had the most impact on my work was real-time data combined with eliminating the backend API development; that combination greatly sped up building the systems. This mattered most because our system needs to process tasks such as renewal processing, background jobs, and orchestration workflows. Using the AG Grid table was particularly useful, as we have to show renewals that are pending, processing, completed, or failed. Without Hasura, we would have had to create several REST endpoints, polling APIs, and manage WebSockets, along with manual filtering APIs. Hasura has changed our approach by handling API generation, GraphQL queries, subscriptions, and filtering, allowing the frontend to no longer wait for backend APIs to make changes.

Hasura reduced backend boilerplate and enabled real-time operational dashboards by automatically exposing database changes through GraphQL subscriptions, allowing our services to focus only on business processing while Hasura handled API generation and live data.

In my opinion, the best features Hasura offers are the auto-generated GraphQL APIs, as it has auto-generated GraphQL APIs and instantly provides queries, mutations, and real-time subscriptions. The frontend can fetch whatever data it needs, instead of fetching huge payloads. Since we used AG Grid for showing huge datasets in a table, the filtering and querying capabilities were very powerful, and the role-based security implementation with Hasura is also commendable.

Hasura positively impacted my organization by facilitating fast development; we saved a lot of time in development. I can estimate that we saved significant time; we do not need to manually create all the GraphQL queries or API generations. I can say we could build an API within hours instead of taking days.

The time saved reflects a significant return on investment.

Regarding needed improvements, the complex business logic, nested joins, and over-fetching need to be addressed. Additionally, Hasura needs query limits, caching, monitoring, and better handling of database coupling.

I have been using Hasura for three years.

In my experience, Hasura is stable.

Hasura's scalability is good, but it heavily depends on proper design; while Hasura can scale horizontally, scalability mostly relies on database design, caching, and subscription management.

I have not reached out to customer support, and we have not faced that many issues.

I did not previously use a different solution with this company.

Before choosing Hasura, we evaluated other options; we traditionally used REST APIs by building backend services in ASP.NET Web API, along with using Node.js, Express, and Java Spring Boot. The old approach created too much boilerplate, requiring a controller, service, repository, and mapping validations for every table and making our frontend heavily dependent on the backend.

My advice to others looking into using Hasura is that if they have an automated system such as auto-renewal, or multiple source systems to deal with while using GraphQL, then I would suggest going with Hasura. I rate this product a 9.

My main use case for Hasura is to create endpoints that I can use to create, get, or update endpoints to my database. My database is on-premise, so to protect it from attackers, we hide it and give access only to Hasura with all the connections from the application directed to Hasura, which connects to the database and returns the answers.

A specific example of how I set up Hasura is as follows: first, for any table, I create the table in the database, then I come back to Hasura and reload the schema for the connected database. Once the database is reloaded, I go to the tracking section and track the table that was recently created. After that, once the table is tracked, I go to the GraphQL space and select the table as well as the columns I want, and it will generate the GraphQL query. I give the return type and save this with a particular name, which acts as the endpoint for my application to access that particular table.

In my experience, the best feature Hasura offers is its scalability.

Hasura's scalability stands out for me as we had a development server and a production server, and we needed to set up a user acceptance test server, UAT server. For this, all we had to do was set up a few connections, then copy the metadata and load it back to the UAT servers to get started. The migration from one environment to another was very fast, which was very helpful. Regarding reliability, the SQL server can mostly have many concurrent connections and can have issues, but in such cases, the load falls onto Hasura, and it handles it very well. All SQL errors or messages reach Hasura at the end, so we do not need to go back and check it on the SQL layer.

Hasura has positively impacted my organization as before Hasura, we used to write the GraphQL code and REST APIs for every table. After Hasura, it is just connecting the database to Hasura and then creating a GraphQL query and setting it as an endpoint. That is much easier than the process of writing the REST endpoints at the code level on the backend server. This makes the implementation much easier and many things easier overall.

I have faced some pain points regarding the migration process.

Regarding needed improvements about migration, if a company has a single development server and multiple production servers, this segregation can be done at the database level or at the level of tables migration. This could be improved.

Regarding my main use case with Hasura, the graphical user interface, GUI, the web interface that is offered is particularly very slow if you have a lot of endpoints configured. It is better to use CLI, which is the preferred method for me. All the endpoints are very fast and responsive, as Hasura servers are very fast. The setup does not take a lot of time as it is just one metadata file, and we can recover all of the set endpoints, making backing up and storing everything very easy.

I would like to add that the user interface is particularly very slow and sometimes overwhelmingly slow. This is not about the response of the endpoints, but rather the user interface itself.

I have been using Hasura for one year.

In my experience, Hasura is stable and has been reliable day-to-day; I have never faced any downtime.

Hasura's scalability has handled growth or changes in my workloads very well.

I have not needed to reach out for help, as I never reached out for any support.

I did not use any other solution before Hasura; I am a fresher.

Hasura's integration capabilities with other tools or services I use are easier to integrate. It is a pretty easy setup; once we have a subscription, we can plug in the database credentials and then get started with creating the GraphQL. This is a much easier process compared to manually creating those endpoints at a backend.

Hasura saves a lot of time for my team; just for a single table implementation, it would have taken one or two days, but now it just comes down to one or two minutes.

Hasura's monitoring and logging capabilities are sufficient for my needs; we can integrate Prometheus and Grafana for monitoring. I collected all the logs and metrics from Prometheus and connected them to the Grafana dashboard, from where I can visualize all the issues that are occurring.

The experience with pricing, setup cost, and licensing for Hasura was handled by my organization.

I have seen a return on investment with Hasura, as the time saved is significant at 70% less time dealing with database queries and REST APIs for development, which saved a lot of people's time.

My advice to others looking into using Hasura is to look into it if you want to reduce your backend APIs, as that can be drastically reduced.

Based on my experience so far, I do not think there are any other improvements that Hasura needs. I would rate this product an 8 out of 10.

For one healthcare project, we have used Hasura as a full back end, and we have the database and all those things inside Hasura. We have created the APIs using GraphQL inside Hasura and the actions, triggers, and cron jobs, all using Hasura.

We just need to define some query in the cron job, which we need to run on a particular schedule that we define. That can be defined in cron job and scheduled triggers according to our business logic use case need.

The instance management is very easy for an application. The first time when you set up Hasura, you need to properly check the DB configuration connections, and the rest is easy. If you want some custom business logic, you can define that in actions, cron jobs, triggers, or whatever you want to create on Hasura.

The best feature which I liked in Hasura is the cron job and scheduled triggers. Apart from that, actions is also a good feature.

Earlier, we took around maybe two days to create some APIs and set up DB and other things. In Hasura we can create tables and relationships and APIs in the end. DB creation, configuration, and deletion of rows are very easy in Hasura. Earlier, where two days were taken, now we can only do it in half to one day at max.

In development effort, very much time is saved, and the execution is fast.

There is always a scope for improvement.