I am struggling to understand Hasura DDN.

[Code-Divine]

I am using Hasura v2 in production and it's been awesome. I can't be more happy with your product. But this new Hasura DDN I am struggling to understand why it exists. I installed it and tried it but I can't see a single new feature, but I can see few downgrades. Namely:

1. Getting hasura v2 up and running is a matter of 2 minutes, download docker image, set some variables and run. DDN it took me 1 hour to install, no docker image (or at least not documented) and it's very poorly documented. It shows me how to start to write models which is not something I would like to do. I connect the database and it should recognize everything like V2 does. I only use Hasura to autogenerate graphql api-s. I don't want to write anything, let alone database models manually. I know this is optional, but why show it at all in a installation guide.

2. The UI is sluggish. It's like it's running at 10 FPS. We need functionality, easy readability not fancy 3D animations.

3. The whole concept of supergraph just seems strange. What is new here that V2 can't already do? And data federation? I can already add multiple data sources in V2 and do joins between them. What is actually new and better here other than I guess properly naming a feature that already existed? This is a legit question, I am trying to understand.

4. And the new pricing $5 per model? How can you charge per model? So as a startup we have 150 models in the database because it's a complex healthcare system but we have only 200 clients so far and we run Hasura V2 on 2 Core system with 10% utilisation during busiest periods. And if we switch to hasura enterprise we need to pay $750 per month, for an app I host myself? That is nuts. I pay less for the hosting itself on Azure. More realistic is to pay $50 per month.

So what is actually new and appealing to migrate to Hasura DDN? And lastly can we use the V3 engine with the old Hasura console or it's tied to Hasura DDN?

[hgiasac]

Hi @Code-Divine,

1. Getting hasura v2 up and running is a matter of 2 minutes, download docker image, set some variables and run. DDN it took me 1 hour to install, no docker image (or at least not documented) and it's very poorly documented. It shows me how to start to write models which is not something I would like to do. I connect the database and it should recognize everything like V2 does. I only use Hasura to autogenerate graphql api-s. I don't want to write anything, let alone database models manually. I know this is optional, but why show it at all in a installation guide.

Hasura DDN is a bit more complicated because the stack is a composition of many microservices (engine + data connectors). There are no fixed docker-compose templates as Hasura v2. However, getting started with the DDN CLI that generates the project boilerplates for you is easy. You can create projects quickly after getting familiar with the CLI.

2. The UI is sluggish. It's like it's running at 10 FPS. We need functionality, easy readability not fancy 3D animations.

The 3D visualization for supergraph models could be heavy on low-end laptops, but it may be useful to view the relationships between models or capture diagrams. The web console in Hasura DDN is designed differently from Hasura v2. Most of the features are read-only and playgrounds for your API models. We have moved the metadata editor to VSCode LSP and DDN CLI for better UX performance. The lesson that we learned from Hasura v2 is that there are many performance issues on the web platform when editing large metadata. In a local dev or self-hosted environment, you can run the DDN engine without needing the web console.

3. The whole concept of supergraph just seems strange. What is new here that V2 can't already do? And data federation? I can already add multiple data sources in V2 and do joins between them. What is actually new and better here other than I guess properly naming a feature that already existed? This is a legit question, I am trying to understand.

You can consider a supergraph as a Hasura project in v2 that includes all data sources, authz, remote schemas, actions, event triggers, etc...

• The data source in v2 is equivalent to a connector.
• A subgraph is a group of connectors (data sources).

Those terms exist in Hasura v2. We just standardize the specification so it can be general and extensible for more complex architectures and enterprise-grade applications.

4. And the new pricing $5 per model? How can you charge per model? So as a startup we have 150 models in the database because it's a complex healthcare system but we have only 200 clients so far and we run Hasura V2 on 2 Core system with 10% utilisation during busiest periods. And if we switch to hasura enterprise we need to pay $750 per month, for an app I host myself? That is nuts. I pay less for the hosting itself on Azure. More realistic is to pay $50 per month.

That's the pricing per active models. A model is counted as active if there is at least 1 GraphQL request query that model in the month. If the model is tracked but no GraphQL request happens it won't be charged. Hasura DDN is still open source and free for self-hosted if you can though.

So what is actually new and appealing to migrate to Hasura DDN? And lastly can we use the V3 engine with the old Hasura console or it's tied to Hasura DDN?

No, you can't. You can use the Hasura v2 console as a database admin tool and CLI for database migration, but the structure of DDN metadata is completely different. V3 engine can't understand Hasura v2 metadata.

The benefits of Hasura DDN over v2 are:

• No need for a separate PostgreSQL database to store metadata.
• Static metadata, fast metadata loading, and inconsistent metadata errors don't exist. Because metadata in Hasura v2 is dynamic in PostgreSQL and allows live editing, inconsistent metadata sometimes happens between replicas (pods). Fetching metadata from the database through the network also adds more latency.
• Support wide-range of database systems for free. In Hasura v2, other database systems are supported in paid and enterprise plans only. The specification of connectors in Hasura DDN also easier for you to write a custom data connector in any language.
• Free built-in OpenTelemetry exporters for observability monitoring. In Hasura v2, it isn't available in the OSS version.
• And more cool features are in development such as PromptQL AI, etc...

In other words, Hasura DDN has better API designs and extensible specifications. The new version solves existing issues of Hasura v2. Hasura v2 is still a great all-in-one solution for most of your use cases. IIUC your startup is small and uses PostgreSQL data sources only. So it's fine to continue to use Hasura v2. When your project grows and performance issues happen, or you need to use other database systems besides Postgres, you should consider migrating to Hasura DDN.

[seanparkross]

Hey @Code-Divine Hi Nenad.

Could you let me know which parts of DDN documentation you didn't like? We're almost finished a major restructure of the docs there.

Thanks
Sean

[maxcan]

@Code-Divine I've been a fan of Hasura for years, and an early seed stage investor and i think Hasura 2 absolutely hit a home run in terms of its level of abstraction. However, I do see the limits they were running up against in terms of the legacy code base.

Having said that, I'm 100% with you on DDN. The "active model" pricing makes no sense except for large enterprise clients. To be honest, thats who they're targeting. I get going after the enterprise but its a shame that Hasura 2 is basically a dead end for solopreneurs and small companies.

[Code-Divine]

Hi, @hgiasac thanks for the detailed explanation. I have much better understanding now. OpenTelemetry exporters in the free version is nice.

@seanparkross I guess my comment on the quickstart guide was based on an older version of it. I see you improved on it and it's pretty good now. The older version I read had something like 'create your first model' which is gone now, but that was few months ago, maybe I am wrong.

@maxcan I couldn't agree more that Hasura is an excellent product. It speeds up development time tremendously. However they do need to remember that those small companies are what later become large companies. And it's good idea to hook them up from the start.