Thanks for the support Ben!
In the long run, it’s probably somewhere in between.
We’ll be integrating Dgraph heavily within Hypermode, we think one of the best ways to create a great developer experience is through tight integration between the layers of the stack. For many users, they might not even know they’re using Dgraph.
That said, we expect that many teams with want to access the underlying data to power other non Hypermode applications. As such, we’ll also expose a hosted version of Dgraph. Those who currently rely on us for hosting will have a home with Hypermode both today and in the future.
Dgraph (and Badger and Ristretto) will remain permissively licensed. We’ll keep improving and investing in it. The goal is to over time make the Dgraph community more like PostGres/Cassandra/React where there’s a team of maintainers at a few commercial entities but the community is also able to contribute/steer to the core project.
As a “customer” of Dgraph we’re going to be leaning into GraphQL. Though our secret sauce will be the inference engines that will abstract the backend into “chains” of functions that resolve whatever intelligence your app needs.
Regarding DQL, there are just some things that you can’t express via GraphQL, as such DQL will remain supported as means to execute those queries.
There’s a much much much longer answer I owe the community about where we want to take the database, but regardless we’ll partner with you all to make sure that folks can get what they need out of the database.
Hypermode has an “open platform” mindset towards infra, models, databases, etc. We plan to make public APIs between each layer of Hypermode to make it easy for folks to map their stacks into our workflow. It’ll be limited to start, but over longer periods of time developers should be able to zero-config integrate other databases/data sources along with models, ml ops tools, etc.