Hey guys,
I’ve been absent for the most part – sorry about that. It’s because of reasons beyond my control.
I’m around here and will keep a watch on this thread. AMA! I don’t promise to give you answers to all of them. But, I’ll do my best.
Cheers,
Manish
How can we help?
Ha, I was about to type the exact same words
In the short term, you guys can’t help.
Back story – we had to do major layoffs in June after we failed to raise a bridge round. We then tried to raise an outside round in Aug / Sep, but failed there as well. We’re investigating options about how to keep the project running.
I’m sure there would be an outcome here, where we can continue building Dgraph. But, it would only become clear over the next few months. My hope is that the community can play a bigger role then.
I have always believed Dgraph should exist. It has clear benefits in both Graph DB and GraphQL space.
So I can’t help with the funding issue, but there is more to it than that, right?
Need help with docs, blogs, awareness??
Yes. But, I think before that the direction for Dgraph needs to be clear. As mentioned in the other topic (what is Dgraph lacking), we need to choose who is Dgraph’s main competitor – is that a Neo4j, or is that a Firebase. And then go hard after that.
I suspect Dgraph perhaps needs two forks – one to go in the Graph DB direction. And another to go in the GraphQL / Firebase direction.
What do you think about raising money from your customers? Gumroad raised $5m from users and external investors via Republic
Have you considered adding more pricing plans? $40/m is too expensive just for testing purposes, but 1mb is not enough. However, I’d pay $10-20 for a limited Dgraph instance to use for staging/side-projects/testing.
What is your vision for the future of Dgraph as a technology? What do you want to achieve with Dgraph?
What’s are the biggest challenges for you and Dgraph right now aside from the funding issues?
In another post you mentioned that the VCs you have spoken to aren’t bullish on graph databases—what is your belief about the future of graph databases, do you see graph databases as tools for niche use-cases, or is there a bigger future for graphs?
Could it be plug-in into the core? So the core is Dgraph with DQL and then plug into that with GraphQL, Cypher, Gremlin
No, we didn’t consider that. I think Dgraph really belongs under a foundation.
No, we didn’t. Though, one can always run Dgraph instance locally – that’d be free to run.
Dgraph’s vision was always to go after application DB market. That’s why we didn’t build a lot of graph algorithms, or go into graph analytics space, which is what Neo4j has pioneered.
We did also always believe in the simplicity of GraphQL (Dgraph started with GraphQL in 2015). So, I think a fork of Dgraph focused on GraphQL applications perhaps makes sense.
Motivation.
Databases become popular because a BigCo (like Google) says so. That’s the story we saw with NoSQL, then NewSQL. No BigCo has come out in favor of building a native Graph system. Instead, thanks to Facebook Tao, the world is stuck with a graph layer on top of MySQL.
Because of these reasons, Graph DB market would never be fully accepted by mainstream developers.
Having said that, graphs can play a much bigger role in building a GraphQL platform, as long as they’re invisible to the naked eye – which is what we were aiming for when we went for fundraising.
It could. But, then you have a marketing problem. GraphQL developers don’t want graph DBs. Graph DB developers don’t want GraphQL. It’s not a technical problem, it’s a “focus” problem.
I want GraphQL and a Graph DB, maybe I am not alone? Most GraphQL people don’t fully understand the problems though with GraphQL as a layer. They don’t get the GBAC value over RBAC and ABAC. They think the n+1 problem is solved when it is not, it is mitigated causing other potential problems.
It is really hard to comprehend data outside of documents and tables/rows for those who have been stuck there their whole career.
How do we flip the script with GraphQL devs? Maybe a rhetorical question, so I’ll rephrase. How do you think we can better combine GraphQL and Graph DB into a more cohesive solution. Push for GraphQL spec changes? Put more graph algos into GraphQL so people see the power? Thoughts?
GraphQL devs want Firebase replacement. Focus on that. And remove anything else that might be a distraction. Which means, don’t expose DQL, transactions, facets, etc. – that’s my take on this issue.
I can understand that. But if the GraphQL layer can’t do EVERYTHING that needs to be done with the data, then you have to expose the lower levels somehow. I think we need to relook at who GraphQL devs are and break them up into frontend GraphQL devs and backend GraphQL devs. If I am delivering a GraphQL API then I need to be able to control under what I am delivering. But if I am building a front-end on top of GraphQL (focusing on apps only) then I don’t care for the most part about what is under the API. If I am fullstack then I want easy middle ground API to speed up front-end but power tools when needed to tweak the “engine”
For example nested filters is really difficult with GraphQL at the moment (I would say impossible, but it is possible with multiple round trips, not best GraphQL performance). And fixing relationships from live loaded data is impossible without DQL.
I suspect learning a new language (DQL) is probably not a great answer for tweaking the engine. That’s where some better tooling would come in handy.
But, yeah – I should add, it’s hard to know without talking to a bunch of new comers to Dgraph, who came for GraphQL. Would they want to learn a new language (DQL)? Or, do they just want some tools to modify data if they need to? What does Firebase do?
I’ve talked to a lot of new-comers. Do you want their voices?
They say almost in this order:
Sure, but that’s not gonna get more dollars coming into Dgraph Labs’ bank account! (Which is the issue I was speaking to). A lot of users don’t want the hassle of setting up an instance on DigitalOcean for a quick side-project, they’d rather spend $20/m for a one-click instance. If you add more pricing options you will make more revenue because there are different cohorts of customers who are willing to pay different prices for different levels of service. The lack of hobby-plan is lost revenue that could be collected (assuming it doesn’t cost you $20/m to run a $20/m instance).
I’d imagine that displacing Neo4j needs to be a longterm goal—it’s such a big mountain for an underfunded company to climb, displacing Firebase is a really large, immediate and achievable opportunity because right now there are a lot of people trying to find an alternative to Firebase (many of Dgraph’s GraphQL customers are devs who have jumped ship from FB)… Dgraph is perfectly positioned to solve this problem.
Kinda seems that Dgraph is trying to drive two race-cars at once, the speed at which you ship GraphQL improvements is constrained by improvements to the underlying graph db layer. However, not all improvements to the graph db layer make a meaningful difference to GraphQL users, performance is probably a good example—performance improvements are welcome, however, my guess is that most GraphQL users really care about API upgrades so they have more flexibility in how they fetch and update data.
If you’re under-funded then you need be as lean as possible, from my outsider’s point of view it seems like the smartest thing to do would be to focus on one thing so you’re able to move as fast as possible in one direction (with minimal constraints). If you chose to make GraphQL the main focus of the company’s efforts it’d mean that any work done on the graph db layer is restricted to only what’s necessary to enable specific GraphQL features. This surely would simplify operations and allow you to continue in a leaner way until the company’s traction increases at which point you can resume efforts on all the graph db work that is not directly relevant to GraphQL functionality.
This is understandable! Tbh when I look at Dgraph I see an absolutely heroic technical achievement. If you guys are feeling burned out then that would not be surprising to hear at all.
Would love to hear you elaborate on this more, because I from what I’ve witnessed in startups, they succeed due to focussed vision and passionate drive to solve a specific problem. This is IMO the most critical problem that any startup needs to have solved. From my outsiders perspective, the best way to mitigate burnout is to simplify the vision.
In fact, this is probably why most successful startups really take off right after crossing the “trough of despair”—because when you’re close to the edge of failure it forces the company to completely lean down and it is this process of throwing stuff out (ideas, implementations, processes etc.) that you remove hidden sources of inefficiency, i.e. things that are slowing you down, burning you out—and this is actually what enables the company to take off.
If startup history is anything to go by, it sounds like you guys are actually at the inflection point and ready to take off. You’ve spent your time figuring out what to build up until this point, now you need to figure out what to let go of? When I read through comments on the forum and Discord it’s really clear what Dgraph customers want—a better GraphQL API that is easy to use. IMO the things to let go of are anything that doesn’t directly speak to that problem.
This clip of Jony Ive talking about Jobs’ definition of what real focus means is something I keep coming back to when I think about this stuff.
Really tricky talking about this stuff, because burnout is so personal. Just know that many of us want to see you personally succeed at this, the passion that has been poured into this product is clear and you deserve to win. My DMs are always open if there’s any way I can help problem-solve.
If the same questions keep coming up, just having blog posts or discuss topics do not solve the issues. Something needs to change to prevent these things for smooth user adoption.
First of all, I want to thank you for creating this thread. No one asked you to, and you realize how important this thread is for some of your users. I realize I have been one of your strongest critics, but I only do that out of love for DGraph and frustration with lack of communication. Not getting a response is always worse than a negative response. That being said, I do hope you realize you have a team of people (including myself) ready to go to help promote, improve, and help you and DGraph as much as we can. Unfortunately, we are not GO programmers, but mostly front-end. However, there is a lot we can do when we get to that point. Just give us the word and we can help with things like Documentation, building demos, testing, etc… free.
I disagree with the fork entirely. I’m not even sure what that would solve. The fork (the direction you decide NOT to focus on), will just lose stamina and interest.
Pardon my candor here, I honestly don’t mean to offend. I don’t believe the TYPE of database is the problem at all. Graph databases are perhaps the most powerful database there is for queries. If DGraph goes to the dirt, another Graph database will eventually be seen. Firebase is the worst noSQL database I have seen as far as features etc. It is just a plain terrible database. Mongo now has features that make it usable, but I would use DGraph in its current state any day before I would use Firebase (Firestore) for a professional project.
The problem is NOT the database, but the marketing.
I have thought about this a lot.
With the right marketing, you should be saying things like “the FIRST fully functional graph database full end platform.” DGraph right now as it stands does things no other Graph database can do. It is self-hosted. You cannot use neo4j without spinning up your own custom middleware. It is not ready-to-go.
DGraph is 100% unique in so many ways. As I have said before, you only have a few real competitors on the front-end dbaas market.
There are NO real other competitors that are ready to go out-of-the-box. Even most mySQL providers require you to write your own middleware.
That middleware (even at 80% and not 100% read-to-go), is fire. That being said, you ARE a graph database, which is what GraphQL SHOULD be using under-the-hood.
Stop apologizing for being the first Graph Database platform, and own it! Advertise both, use both, and develop both!
That being said, with limited resources, you must look at what is really important to develop, and what is not. For GraphQL, there are some things we can’t do without for real product:
These three things alone give us the tools to build our own work-arounds. If we can write our code in the schema or keep our current GraphQL nodes, it will not deter people from the extra work involved. Pre-hooks and Custom DQL Mutations both should be able to be written in less than a week. Field Level Auth is necessary for security, and the only complex feature we can’t live without. VERY necessary. All the other features (nested filters, facets, cascade issues, etc) can be worked out later, and right now with custom dql queries etc. You need to tighten up security big time, and allow us to write our own middleware if you don’t have the resources to do it.
I think you need to understand GraphQL is almost where it needs to be to compete with the big dogs. It is just not quite there. The Graph Database indexes and algorithms, however, may need a lot more love (I don’t know).
Don’t fork the project. Tighten up GraphQL, then focus on the core database for a while. If and when you see your userbase change, go back to GraphQL. Keep updating it here and there.
You think there are 50 feature requests, but there are only a few main concepts that Dgraph is missing. The stuff that has never been done before is for later.
Your true product IMHO is neither neoj’s competition nor Firebase / Hasura… it is a new Field. The FIRST GraphQL database as a service instant API, subscriptions, etc out-of-the-box!!!. @amaster507 has written 50 blog posts about the power of the @auth directive, which can’t be done in SQL on any platform. There are so many things DGraph is good at. Sell the product for what it is.
Questions:
1.) When will v21.12 be released on the cloud?
2.) Where is the current market that are paying users?
3.) What market do you feel you’re missing?
J
I wanted to add there are two projects I honestly believe (with users help as well) I could build.
A Firebase / Supabase - like API that works on any JavaScript platform out-of-the-box. It would use URQL and GraphQL under-the hood. It could work in react, angular, svelte, vue, or vanilla js. This would not be hard to write, as I would use my easy-dgraph under-the-hood, support caching, subscriptions, etc. We would build the website for it, and make it work easily like Firebase and Supabase.
A Firebase like platform for Admins. It would be just like DGraph Cloud’s Data Studio, but you could C(R)UD the data as well with a simple UI. Again, no one cares about Firebase’s database, just the easy-to-use API and UI. I would create an npm package that would run on the developer’s machine, no docker needed. I know this was sort of the plan for Data Studio, but you could focus more on the database issues.
I believe things like this could really help out. So I think you’re wrong when you say there is nothing you all can do. That being said, I don’t want to invest my time into building something like this (which I would enjoy doing), unless I am sure DGraph is going to exist in a year. So, keep us updated as soon as you hear good news (which you will).
P.S. Instead of changing your pricing model as @BenW suggested, perhaps you could just expand the amount of data transfer it can do to something realistic for testing purposes… just a thought.
P.S.S. @mrjn - I can’t give you motivation, but I can tell you “thank you,” from my nerdy heart, for the great product. I asked for it back in April 2020 jokingly on stackoverflow when I was trying to solve a Firebase Problem (— I started in mySQL btw), little did I know it was a possibility.
Totally agree with the assessment. Most of the problems that GraphQL customers have are not super technical problems, they are ‘friction’ problems. IMO it seems that if Dgraph focussed more on onboarding, developer experience then developer adoption will take off.
DQL is crucially important for situations where you need a workaround. I think what needs to be done is to focus the docs on GraphQL, and cordon-off the DQL docs into an ‘Advanced’ section of the docs.
This is a great point, Dgraph is its own category (perhaps along with Fauna and Arango, which is graph-backed GraphQL generators), which is perhaps why it’s hard for a lot of new users (myself included …initially) to get why it’s so powerful. I imagine the most effective marketing strategy for Dgraph is not to market itself as a competing product in the GraphQL generator market, but best product in the subcategory of Graph-db powered GraphQL APIs or *Instant GraphQL API BaaS Tools".
Dgraph needs to focus it’s marketing on educating users on what this category of products is all about, i.e. why do we need our GraphQL APIs to be backed by Graph DBs? Why are the existing GraphQL solutions not good enough (and naturally why Dgraph is the best in the category). (I’m aware that Dgraph already does this, I just think it’s unfocussed).
I think part of Dgraph’s problem is that it markets itself as being in multiple categories, it’s in the category of “Graph Databases”, it’s also in the category of “GraphQL Generators” but really both these categories are saturated (meaning it’s hard to differentiate yourself). The right approach is to create a new category, and be loud about what this category is—this is how Dgraph makes it clear how it is differentiated.
Basically, it’s not clear to a lot of Hasura users why they should consider Dgraph. But there are a lot of people out there who:
These are things that Dgraph is almost uniquely positioned to solve, however, it’s not obvious when you compare Dgraph to all the other GraphQL generators. These facts do become obvious when customers are educated about the fact that Dgraph is not in the same category as these other products, and you do that by marketing the category.
In the past I’ve said that the graph db aspect of Dgraph should be treated as an implementation detail in order to make the product less scary to web devs like myself who don’t have PhDs in computer science. But perhaps the actual problem is not that Dgraph is built on top of a graph db layer, it’s just that new users feel that they need to understand how graph databases work, and how to use DQL in order to use Dgraph (which technically they don’t).
Dgraph should be emphasising that the graph db is what makes it different, while at the same time making it clear that you get the benefits of this powerful graph database without having to learn Gremlin, Cypher and how graph algos work.
I think Dgraph needs to be more loud and opinionated about its belief that graph databases are the future of GraphQL APIs.
More about this:
YES!!!
However, that category should not be limited to just GraphQL, but anyone needing any front-end out-of-the-box powerful, zero-config, complex relationship building api!
I don’t think DGraph can compete as JUST a Graph Database, as there are many graph databases. It is SO MUCH better than that, people just need to see it.
This is your product.
A new category in itself…
J
