Retrospection and Learnings from Dgraph Labs
This blog post was on the front page of Hacker News for a day — Link
It’s been almost nine months since I left Dgraph Labs, a company that I spent 6 years of my life building — after a layoff followed by a failed Series B round (unsurprisingly, and in that order).
During this time, I’ve had a chance to reflect upon what happened, what went wrong, what went right, where did we succeed, and where did we fail — and most importantly, what I learned from this entire experience.
First, let’s tackle the hard one. Where did we go wrong?
1. We didn’t process investor signals
Most investors I talked to weren’t sure about the graph database space. The space hadn’t seen a clear exit or a massively successful startup. The adoption curve of the technology wasn’t spectacular.
That viewpoint didn’t change from our first seed round to the second, to Series A to finally, the B round. Not only investors but most developers also weren’t sure when to adopt a graph database and what’s a clear use case for it.
In retrospect, these were apparent signals to pivot to another field, where this technology can be more directly applied with clear wins — allowing us to fundraise efficiently and attract more talent and users.
2. We missed the GraphQL train
We were on a mission to become the application database. And we had bet upon GraphQL very early on. However, we didn’t fully commit to it. The spec just wasn’t designed for a database system. We built our flavor of GraphQL, which allowed for more complex expressions and was easier to work with but simply wasn’t the official spec.
Initially, we got traction from the front-end community, who was excited about a GraphQL database. But, because we didn’t fully follow the spec, we found ourselves out of the GraphQL conversation.
Not supporting GraphQL meant the front-end community couldn’t use Dgraph to build their apps. Not supporting Cypher meant Neo4j customers couldn’t switch to Dgraph easily. Following either of them religiously could have given us clarity and focus.
Sometimes following a standard means adopting its ugliness. And you just have to bite that bullet because it allows a much wider audience.
Because we didn’t follow a standard or focus on providing a solution …
3. We built too much
We started with the idea of building a Spanner-style graph database. The problem was — there wasn’t enough conviction in the market itself, so building a more complex software that would take more resources and time just didn’t make sense, particularly without the massive invesment that a database company needs. As a rule of thumb, a typical DB company takes 50M in funding to get to a working product.
A wiser thing to do there would be to realize that there isn’t enough funding to build a graph Spanner. So, instead, focus on building enough to grab customers from the top player in the field. Building a single server database is a LOT easier task than building a globally scalable, synchronously replicated, sharded database with fault tolerance and distributed transactions, and passes Jepsen tests. Each of those things added a year of work — a year spent building and not selling the software or talking to customers.
When a market is saturated, a better product wins. For example, it makes sense to build a better SQL because the market is already well educated about the usage of the technology.
When a market is new, better marketing wins. For example, it makes sense to educate the market about graphs, even with a simpler product, so devs understand when to use it and how. Not knowing how to position or market the software cost us dearly.
Moreover, most developers don’t know what a graph database can do. Many have had negative experiences using one in the past. To deal with that, a clear, solution-based education would have served us better, particularly when coupled with a “try it on the cloud”.
4. We took too long to launch the cloud service
We launched the cloud service way too late. For the longest time, we were purely reliant on on-premises deployments. The problem was that it’s hard to convince a DevOps person to add a relatively unpopular database to the tech stack. However, the same person won’t bat an eyelid (slight exaggeration), adding a new cloud service to the stack. Cloud is easy to try out and easy to adopt with little work and operational headaches. The “wao factor” is a lot easier to achieve.
When we finally did launch the cloud in Q2 2021, our revenue tripled in a few months — we had never seen anything like it. But, it was too late.
Cloud also helps you focus on paying customers. Open-source is a double-edged sword. You have a lot of users and a lot of adoption, but no customers. We had thousands of Dgraph instances running in the wild but very little revenue to show for it. Moreover, prioritizing the right features which can generate revenue becomes hard when you have non-paying users.
I’ve been a huge fan of open-source, and have built many popular open-source softwares. But, it’s clear that software as a service is winning over open-source software. When adopting a service, most customers don’t care about whether it’s open-source or not. But, even if it’s open-source, a hosted service makes for much better adoption. Cloud is the right platform for generating revenue, irrespective of whether you’re open-source or not.
Cloud is eating open-source software
In fact, cloud bets are so strong that many previously open-source companies have pivoted to non-open-source licences, to tackle AWS and other cloud providers who can steal their lunch.
Now, this would be different for a startup whose main competitor is a hosting service provider — for example, when you are competing against Google Cloud Spanner, or Amazon S3, or Slack. Their customers would be folks who already know they want the software but have reasons to run it in-house — some combination of cost and privacy.
But, it didn’t apply to us. Our users still needed conviction about why they should be using a graph database. And having operational costs coupled with a steep learning curve to try it out meant they’d instead build a graph on top of some already familiar database or rearchitect to avoid a graph altogether.
5. Companies are all about people
A big part of the learning was around evaluating people. In fact, we got that wrong in a very fatal way.
As I was stretched too thin (particularly around the time my son was born), we brought in a well-liked but inexperienced CEO at a time when we were still looking for a product-market fit. By the time the CEO came in, we were on a ticking clock to run out of money but were promised a bridge round.
The new CEO took the conventional approach and recruited to establish an enterprise sales operation, even though our recently launched self-service cloud operation was experiencing promising organic growth. This led to the two strategies conflicting. The CEO questioned the necessity of allowing online credit card payments, while his newly brought in salesperson stopped a cloud customer from upgrading in order to generate a commissionable invoice.
Critically, the CEO neglected the fundamental rule of securing funding six months before running out of money, placing excessive reliance on the promised additional funding round which ultimately did not materialize. When the CEO departed, our burn had accelerated, leaving us with just six weeks of operational capital.
The appointment of the CEO also unexpectedly divided the board. Instead of resigning, I attempted to salvage the company and subsequently, was held responsible for the crisis. Already long battling depression, after five months of futile efforts, I had zero motivation left to continue.
Lots of parallels have been drawn between Dgraph and RethinkDB. My take is that RethinkDB wrapped up slowly due to lack of revenue. Dgraph took a hit suddenly due to a critically wrong hire — which made us go from a “things are looking great” to “sorry, you’re out” within a very short period of time.
Now that I’ve jotted down all the things that either went wrong, or we could have handled better, let me contemplate what did go right.
1. Proved what a graph database could be
We proved what a graph database could be. It can be a globally scalable, sharded, replicated, distributed, and ACID-compliant transactional system. It was the only native graph database to have been Jepsen tested, and as of today, it still is. Dgraph showed that graphs could be fun to work with.
Being a latecomer to the graph space, we quickly crossed all existing players in our GitHub star traction. With 18K stars, Dgraph became the most starred graph database in the market. Dgraph was even marked as a contender by Forrester — the youngest company to do so. And we achieved all of this on 15 million in funding, a relatively small amount for a database startup.
2. Built a GraphQL native cloud service
We built a fantastic GraphQL Cloud service. Start with a GraphQL schema and get an entire backend setup automatically, with CRUD and search APIs. In a world full of GraphQL middlewares, Dgraph Cloud allowed an engineer to get up and running with GraphQL incredibly easily. The cloud traction was indeed great — going from 0 to 60K MRR in few months.
3. Strong signal of product market fit
We took the product from 0 to 1M ARR, proving a strong signal of the product-market fit.
4. Engineered our way to cloud margins
Dgraph was built as a fault-tolerant system where we could afford to lose one of 3 replicas temporarily without any issues. We used this feature to cut cloud costs. By using Spot instances to run Dgraph replicas and perfecting the ability to switch out machines on the 2-minute notice that AWS provides, we were able to reach impressive 70% margins even on moderate instance volumes.
5. Advanced the Go ecosystem
We built not only Dgraph, but also Badger, Ristretto, Serialized Roaring Bitmaps and, Manual Memory Management. These libraries advanced the state of the Go ecosystem by bringing the best of other languages. Badger, in particular, gained a lot of traction and sat at 11K+ GitHub stars itself.
It took an immense engineering effort to achieve all these things, with people working day and night. I’m proud of my team and what we built together; and thankful to the investors who believed in my vision and invested in the company. And I honestly wish I could have produced a better outcome for the team and our investors.
Conclusion
Running a startup is a complex mix of the right idea space, the right timing, the right people, the right execution, and luck. You need to get a few of them right to make a company successful. Identifying which ones are those is the key to success.
Starting as an extremely awkward tech nerd, I learned a lot from my journey building Dgraph Labs — I’ve evolved as an engineer, founder, manager, and leader.
Most importantly, I’ve started to listen to and believe in my gut, in my instinct. For a logic driven person, a heart-over-mind approach is the hardest to build. And that, to me, is my most precious learning.