Recommended Resource Limits for Hasura CE 2.12.1

[IsaacLeeWebDev]

Does Hasura have a recommended minimum amount of memory and CPU cores for Hasura v2.12.1 CE using the hasura/graphql-engine:v2.12.1.cli-migrations-v2 image? Does it change if we use the -ce image?

I've seen this page of the docs on the recommendations for EE but it's not clear to me if these are also good minimums for Hasura CE.

I've also posted this question in the Hasura Discord, and I'm happy to copy over any answers I get from either place the other.

[IsaacLeeWebDev]

For anyone checking in on this, this question received a reply on Hasura's discord. The link to the thread is here. Here's the reply so far:

sandip — 12/22/2022 2:19 PM
Hey @isaacl42 The EE recommendations in the docs should be more than generous for basic C.E (and even EE) usage but it's best to first understand how resource consumption in Hasura works:

1. Your DB/GraphQL schema and user/API roles: Hasura generated a GraphQL schema for every role and store this in memory. So, the number of schema elements you track (tables, remote schemas) x number of roles correlate with memory consumption. If you have a basic schema and a few roles, 2GB RAM should be enough to support basic throughput (more on this later).

2. CPU consumption: Hasura most CPU intensive task is to convert incoming GraphQL requests into SQL or other requests (to remote schemas, actions), which isn't very taxing. So CPU utilisation is proportionate to traffic (num requests) but the footprint is relatively smaller. There are other CPU bound tasks as well (like processing event triggers, etc.) but the those are small-ish tasks as well.

3. Impact of DB connections: If you throttle the total number of connections that Hasura can open with the DB and continue to respond to heavy traffic, especially the kind that takes a while to execute in the DB, memory consumption will continue to pile up. So much so that if you don't scale out horizontally, your containers will run out of memory.

4. Type of traffic: The more complex a request, the larger its memory footprint will be. E.g. a large query or a long running subscription.

It's hard to use a simple estimator/calculator but we are trying to come up with a simple t-shirt sizing lookup table to make this easier (cc: @david Ventimiglia @Raju Sunny ). Meanwhile, you can benchmark your API using tools like https://github.com/hasura/graphql-bench or your choice of http/ws/graphql tools for this purpose.

What kind of traffic and schema are you looking to support? Maybe we can recommend a sane set of default/baseline for this.