Are you serious? Two of your points are future feature promises. One of them is how Hasura plans to support other DB's besides Postgres, which they've already

Are you serious? Two of your points are future feature promises. One of them is how Hasura plans to support other DB's besides Postgres, which they've already been exclusively working on & supporting for multiple years at this point. Another mentions that you have plans to build a UI for non-technical people. This isn't different either, Hasura already has this too. The triggers part is also downright wrong. Check the technical document on scaling to 1,000,000 live queries. Discussions about the scalability and tradeoffs of WAL, Triggers, and the decided implementation (interval-based polling) are given: https://github.com/hasura/graphql-engine/blob/master/architecture/live-queries.md https://github.com/hasura/graphql-engine/blob/master/archite... "We experimented with several methods of capturing events from the underlying Postgres database to decide when to refetch queries." "Listen/Notify: Requires instrumenting all tables with triggers, events consumed by consumer (the web-server) might be dropped in case of the consumer restarting or a network disruption." "WAL: Reliable stream, but LR slots are expensive which makes horizontal scaling hard, and are often not available on managed database vendors. Heavy write loads can pollute the WAL and will need throttling at the application layer." "After these experiments, we’ve currently fallen back to interval based polling to refetch queries. So instead of refetching when there is an appropriate event, we refetch the query based on a time interval. There were two major reasons for doing this:..."