Hi Manish,
Thanks for giving us the opportunity to give direct feedback like this, it’s really valuable. You really should join the Discord, because there’s a lot of important conversations going on (mostly around how Dgraphers can help Dgraph succeed) and it’d be great to have your input! Click the link below:
In response to your questions:
No, the performance is insane. So good that I have to look at logs to verify that the request actually went through because there was no discernible latency. Currently not working with a lot of data though, although compared with literally anything else I’ve ever used, Dgraph completely knocks it out of the park.
GraphQL transactions are not critical for me right now. I can live with DQL transactions. But what I hope to see over time is gradual improvements in the GraphQL API so I need DQL less and less. GraphQL is preferable because my client can go direct to the server rather than via an endpoint in my app. Plus it has guardrails that prevent me from screwing up my data.
This is the thing I have the biggest opinions about. Essay incoming…
Some of what I’m saying here echoes what others have already said, but it bears repeating.
In short, one of my biggest concerns about Dgraph is that I think it positions itself wrongly. Although the native GraphQL graph database is an absolutely phenomenal achievement—it is what Dgraph’s database makes possible that is most exciting. Which is to become the ultimate backend solution. This is the direction I hope Dgraph decides to take, because:
- It’s what I would invest in if I had the option to
- It’s what will make Dgraph most valuable to my business
- There’s obvious opportunity for growth here
When I look at Dgraph, what I see is a company that has all the pieces in place to become the no.1 backend as a service tool. Currently Dgraph markets itself as a GraphQL generator, however, I think this limits it’s market to developers who know they want a GraphQL API. However, if you market Dgraph as a Firebase killer that can provide all the benefits of Firebase (iteration speed, ease of use) minus the costs (runaway costs and complicated pricing, terrible query performance, vendor lock-in) then becoming the next Firebase in terms of popularity and profits becomes feasible.
Marketing yourself as a GraphQL generator is IMO an example of marketing the features instead of the value. Most developers, myself included, don’t care how something works internally, they just care that a given tool can help them build and ship apps faster and without headaches. If you look at Firebase’s marketing page it doesn’t mention the fact that it uses a NoSQL document store, and it’s because it’s not directly relevant to the problem it’s solving—creating a powerful backend with minimal effort.
As others have mentioned, Firebase is losing customers due to the problems mentioned above. I think a good example of a startup that has suffered as a direct result of being built on top of Firebase is the bidirectional note-taking tool https://roamresearch.com. They chose Firebase presumably so they could iterate fast. In bidirectional note-taking tools, you notes are stored as a giant interlinked graph. Roam has always had big. performance. issues, and as a result it has led to a lot of outrage from customers, which led to 15 or so different companies seeing an opportunity to create competing products. Roam have acknowledged that Firebase is at the heart of their performance issues, and it’s easy to see why; querying graph-structured data from a document store is always gonna be slow.
This has created an opportunity for other Firebase-competitive startups like https://supabase.com. However, none of the Firebase competitors I’ve looked at come close to what’s possible with Dgraph. Supabase for example uses Postgres instead of NoSQL. However, as a Supabase user, although you now have a nice ORM for Postgres, you’re still stuck with the same old query-performance issues that seem to plague every app I’ve build no matter how simple. Plus, you still have to construct your queries and endpoints, and similarly to Firebase your client code is closely intertwined with your backend implementation due to the custom API. Because Dgraph generates a spec-compliant GraphQL API I don’t have these issues, because I can technically swap Dgraph out for another GraphQL API (that can return the same data) and not have to rework my client code.
The performance of Dgraph is a game-changing feature because even if you’re building a simple MVP it means that you never have to worry about having to waste precious time optimising queries. Of course, you know this because you built it! But I don’t think it’s clear from how Dgraph describes itself, or its marketing.
Reading through Supabase’s (an open-source Firebase challenger) Github Discussions, I found some comments about Dgraph as a possible integration, and there’s confusion about whether Dgraph is just a database, or a Supabase/Firebase competitor. This was my experience learning about Dgraph—it wasn’t immediately obvious why this product is so powerful. I initially looked into Dgraph because I have a specific use-case where a graph database makes sense, however, once I realised that Dgraph is basically a BaaS that can be used for any use-case it blew my mind. My thinking has now flipped, Dgraph is the default go-to, and from the conversations I’ve had with other Dgraphers, I see a lot of agreement on all of the above. I also wonder if a lot of those devs who are using Supabase now knew what was possible with Dgraph would still be using Supabase, my guess is that Dgraph if positioned correctly could win over a large proportion of this market.
So basically, I’d like to see a simplified vision for Dgraph, and laser focussed approach to achieving it. Right now, Dgraph isn’t super clear about what problem it’s solving then it’s not clear what products it’s competing with. It’s kind of competing with 20 different products at once. It’s kind of competing with other graph databases, kind of competing with Hasura and other GraphQL generators, kind of competing with other BaaS systems like Firebase. It just needs a clear message about what exactly problem it is solving for the customer and what its mission is.
As for what Dgraph needs to do to achieve this, in no particular order:
- Make it possible to configure Dgraph entirely via a few clicks in the Cloud admin UI. Down to things like configuring auth rules.
- Build a migration tool that makes migrating your data after a schema change as easy as using the Ruby on Rails migration tool
- Directly integrate other tools into Dgraph like https://magic.link, Auth0, and make it configurable with a few clicks
- Invest heavily in education (the best kind of marketing for a dev product). Primarily polished YouTube content.
- Simplify the messaging around the product and what value it creates for the user.
- Detailed and accurate GraphQL errors
- Focus really hard on making it as easy as possible for devs to build side-projects and hobby-projects free/cheap Dgraph instances
- Involve the Dgraph community more in the success of Dgraph, by ensuring there is two-way communication and feedback. At the moment it often feels kinda one-way, we submit tickets in this forum and wait for replies. Dgraph and the community working together is key to the success of Dgraph.
In summary, no-code/low-code tools are one of the most investable areas of tech right now, because web development is getting insanely complex. Dgraph has all the pieces in place to build the ultimate low-code tool. The simpler you can make it for users, the more users you’re gonna get.
I don’t see this needing to be a priority. From my point of view, it’d be a distraction from achieving the goal of making Dgraph into the easiest to use most powerful BaaS on the market.
I’ve had no problems using it with SvelteKit + Awesome GraphQL Client. It’s been a breeze to work with.
- $5-$15 mIni-instances that I can run hobby-projects on. 1mb is just not enough.
- No issues with paying with the current offering