Announcing Hasura Cloud: Managed GraphQL for your database and services

Auto-scale and serverless GraphQL

Each instance of Hasura is a heavily multi-threaded server that exploits shared memory within the instance to aggressively optimise handling GraphQL queries at runtime. If you’re running Hasura yourself, you can first scale a few Hasura instances vertically and then horizontally. At what CPU or memory threshold should you scale up or scale out? Well….it depends. Hasura’s footprint is different for different kinds of workloads.

GraphQL caching (👋 @cache)


  • Hasura GraphQL Engine already supports query caching
  • Hasura Cloud supports data caching by adding an @cache directive to your queries
  1. If the API call doesn’t depend on a property of the user, then it is straightforward to say that all API calls will fetch the same data. The cached data can be retrieved from a cache and sent to the API consumers.
  2. If the API call depends on the property of the user, then we need to know if because of the identity of a user, they would end up fetching the same data that some other user has already cached. Let’s say everyone in the same area fetches the same list of restaurants on their app. This is a dynamic rule, because users can change their current areas and hence which cached entities are fetched depend on who is making the API call at that point.
  1. Cache invalidation is hard :)
  2. When users make API calls that perform writes, busting the cache that the same API server or that other instances of the API server are using, is hard.
  3. This is a version of the materialized-view-dynamic-update problem, but at the application level which is potentially fetching from multiple data sources. This is typically why most application server developers using something like Redis typically set a TTL using information from #1 (Knowing what to cache) and deal with the temporary staleness on the UI side.

GraphQL Monitoring

Apart from monitoring successes errors (and partial errors) from GraphQL API calls and their responses, Hasura Cloud also adds great support for monitoring websocket connections and subscriptions!

GraphQL Tracing with OpenTracing

Strange things happen in production and it’s hard to know where the problems came from. Tracing requests and responses, end to end and through the various components in your system in production is critical.

GraphQL Rate limiting

When you’re running a GraphQL API in production, you might need to add some rate-limiting rules. Especially if your API is a developer facing API and not just used by an app. Rate-limiting allows you to make sure that your server and your data sources are protected from sudden spikes from malicious users and also allows you to make sure that your customers or tenants consume your API within reasonable limits.

GraphQL Query capture

Hasura cloud captures queries (optionally stripping out session and query variables since they might be sensitive) and makes it available to you for 2 main uses:

  1. Regression testing
  2. Bootstrapping and managing an Allow List

Network security

Hasura connects to databases and services running on systems owned by you. For example, you can connect to Heroku Postgres, or RDS, or cloud SQL, or your own Postgres running on your VM.

  1. IP whitelisting
  2. VPC peering / private link



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


⚡️ Instant realtime GraphQL APIs! Connect Hasura to your database & data sources (GraphQL, REST & 3rd party API) and get a unified data access layer instantly.