Comparison with Hasura

Airsequel does not currently support nested boolean expressions for filtering (i.e. expressions involving or operators and the like). When querying, this can be worked around using views. Moreover, Airsequel does not currently have a dedicated is_null filtering field (although the same functionality can be replicated using _eq: null).
Hasura will fail when attempting to create tables <name> and <name>_by_pk (it is not clear what happens when attempting to import a database which already contains two such tables). Airsequel will simply append underscores to the name of queries/mutations until one that doesn't conflict with a table name has been found. This has the advantage of supporting imports of as many existing databases as possible.

The order_by parameter consists of an array of records in both Airsequel and Hasura. While Hasura offers more granular control over where the nulls should be placed among the results (at the start/end), the main two options (asc and desc) work the same way as they do in Airsequel (although in Airsequel the aforementioned lowercase enum variants have been deprecated in favour of ASC and DESC respectively).
While our GraphQL API does not offer a direct way to perform joins, the distinct_on parameter, and aggregate queries, the functionality can be replicated using views.

The on_conflict parameter is similar across engines, although Airsequel allows passing in an array containing more than one such clause (while Hasura allows at most one).
While our GraphQL API does not support insert_one mutations, the basic insert mutations can be used instead.

In update_<name>_by_pk mutations, Hasura's pk_columns record exists instead as a flattened set of arguments in Airsequel. That is, the following two mutations are equivalent in their respective engines:
```
mutation Hasura {
  update_users_by_pk(
    pk_columns: { email: "john@example.com" }
    _set: { name: "John Doe" }
  ) {
    affected_rows
  }
}

mutation Airsequel {
  update_users_by_pk(email: "john@example.com", _set: { name: "John Doe" }) {
    affected_rows
  }
}
```
When a column named _set exists in the table, the _set parameter will have underscores appended to its name until the name is free to use.
While our GraphQL API does not support update_<name>_many mutations (nor their _by_pk variation) directly, one can perform the individual mutations sequentially instead.
Similarly, one can replicate the not currently supported _inc parameter (for incrementing numeric values) by performing the updates using the REST query api instead.

There are no delete-specific differences between the two engines.