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.

A quick, specific example of how I use Hasura for back-end data validation is that we had an integration project from one tool to another tool to Epic and how that data is flowing. All data was integrated in Hasura database. From there I use the queries to fetch the data and find out how the data is integrated and how it is working.

About my main use case with Hasura, I felt Hasura is a pretty user-friendly tool.

What I appreciate most about constructing queries in Hasura is that the entire process is beneficial because it was easy compared to other databases where I can go to the table and select the columns and drag it and construct the queries. The flexibility and the speed are exceptional.

Hasura has positively impacted my organization because for this project, whatever project I'm working on where previously we were using the normal DB2 and which was a little complicated to use, Hasura made it very easy to understand the data flowing and data integration.

Regarding needed improvements, many developers feel that the complex workflow and validations can be difficult to manage at scale, and debugging access issues are a little confusing. These aspects could be fixed.

I have been using Hasura for about one to one and a half years.

My advice to others looking into using Hasura is that it's a good choice; performance-wise it is really good, so I would tell others that you can use it. There will be some challenges such as poor indexing and some inefficient GraphQL queries, but Hasura itself is really fast, so I would definitely suggest it. I would rate this review a 7.

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.

I have used MongoDB and MySQL, and for the last two years, I am using CockroachDB, which is better than these two. I have recommended it to two more of my colleagues who have also started working on CockroachDB, and they are building an application for the global market. They have started using CockroachDB because it has been very helpful.

I am using Hasura just for the GQL, GraphQL.

Hasura has connectivity with CockroachDB, and I am not directly calling CockroachDB, I am just calling Hasura. Internally, Hasura calls CockroachDB, gets the data, and populates it into our application. It serves as middleware.

We have real-time subscription in Hasura.

If I change anything in CockroachDB, it immediately impacts Hasura. For example, if I add new fields, it gets reflected in Hasura.

Integrating microservice architecture with Hasura provides an endpoint to incorporate into your microservices. It works as a connection string, and that's its main role.

Hasura's best feature is that it provides an API gateway, and it also provides remote schemas and monitoring, which are the best methods they are offering.

In the API playground, I can run my query dynamically; it has a GraphiQL integrated system. I can fix my error directly on this playground and then copy my query from it to my code.

Regarding security, Hasura provides API keys and secret keys. It is hosted there and offers these features, which are very good. I have role-based access; I can give four out of five team members access to the Hasura console and manage their access control according to their roles. If assigned as admin, they can do anything. Developers can run queries, and business developers can monitor metrics.

Hasura does not support custom business logic; it just provides Graph Query Language support to get the data. It offers an endpoint where I can fetch the data and create any endpoint, such as ABC, to get a desired output based on some input variables.

Hasura has event triggers, and I have used that feature. I find it effective to have these event triggers in my system.

The main benefits I see from using Hasura include being able to fix my queries on the playground in real-time rather than relying on Google or any AI solutions for error resolution.

One area I would like to see improved is that they are providing a cloud-based DB system, and aside from that, I don't have any additional requests.

I have been working with Hasura for the last six months only.

I have no issues with stability or scalability; everything is good.

I have no issues with stability or scalability; everything is good.

The tech support was fine; they used to reply within one, two, or three days, and that is acceptable.

Before Hasura, we did not have a chance to work on CockroachDB. We used DynamoDB, DocumentDB, and MongoDB from the AWS platform.

The initial setup of Hasura was very easy. Once redirected to the dashboard, I can add a new project by clicking a button for a new project. It asks if I want to go with a free plan or a professional plan, and if I select the free plan, I provide a provider such as Google Cloud, Azure, or AWS. Based on this, I can create a new project and add my DB connection string, such as CockroachDB. Just put it in and click save to create the connection, after which I can launch the console.

My advice for others considering Hasura is that sometimes it may not support capturing remote schemas effectively; for example, if I change something in CockroachDB, it sometimes fails to capture the change until one or two days later. I discussed this with the sales and technical teams, and they also recognized this issue. This can impact your business deadlines if it's not functioning properly.

Event triggers are required for situations such as creating backups every three or four days. For example, if I need to create an event that runs every three days for backups or integrates payment systems using webhooks such as Stripe, once Stripe updates the database, that data will be updated in my local database.

On a scale of one to ten, I rate Hasura a six out of ten.