Dystopian

I worked on an adjacent project with one of their teams many years ago. I was very surprised by how zero tolerance their policies were about receiving anything.

It may have been the team I was working with, but I remember none of them allowed us to buy them coffee from the shop in our lobby when they visited.

If you're using these for purely inference (which is what the 5000 seems like it's tuned for) the vram's the real bottleneck so you get a similar bang for your buck using last gen's cards vs. the bleeding edge.

I've also found the crypto crash has dumped a bunch of these well-worn cards on the market you can pick up a bit cheaper.

Only thing I'd be aware about though is making sure you're on the right side of licensing for all the vendors you're using (/ possibly who you've talked with to make sure the usage is ok).

Off the top I saw N8N on the homepage who are a little more strict about their licensing for cloud vendors. There's also Airbyte and Redpanda who use Elastic and BSL licenses to try and deter cloud vendors from packaging some parts of their services.

The self-hosted community version has full access to JWT and webhook validation.

The SSO listed is a feature to integrate with the Hasura Cloud Dashboard for logging in and managing projects. Think Okta => Hasura Cloud => Hasura Project (Instance). We'll definitely take a look at wording it to make it more clear.

Loved that you mentioned PL/pgSQL - consistently impressed by the amount of logic that can be implemented in database using that or plv8 or its cousins. I personally have feels about why that may be a good solution for a lot of small-to-mid-to-large size build outs.

But yeah, in terms of logic we definitely expect you're going to need at least one other service for auth in the stack (for simplicity that service could also be used for any logic-based work as well).

One of the things we pride ourselves on is being non-opinionated about the logic side of the stack and trying to create as many 'escape-hatches' as possible.

Want to use db eventing? - We can event out to an external service.

Setup a custom action? - We can toss those arguments out to an external service and return a response.

Want to do some magic™ using other GraphQL tooling like Prima or Graphene? You can mesh those in with remote schemas.

We really want to build a tool that helps onboard you into the GraphQL ecosystem, but then scales with you as your stack becomes more complicated.

In terms of query-plan caching - which provides a lot of benefits for speeding up pre-query execution - that's already enabled by default as part of the Hasura engine.

Response caching is a little more complicated and requires a separate service outside of the main GraphQL server to keep the solution generalized (ex. redis, memcached, lots of other options).

We're definitely looking at ways to have some more examples as to how someone could go about rolling their own caching solution for self-hosted instances.

In the case of hosted solutions to caching, there's Hasura Cloud which pairs the cache with monitoring and some other usability and security niceties - but you could also use a service like GraphCDN (there are a couple other as well) in front of your Hasura instance which helps setup response caching.