When I started building the initial version of the Dgraph Go client, we were looking for a serialization format which was fast, easy to use and supported multiple language runtimes. We finally implemented our client using Protocol Buffers which gave twice the speed and consumed two-third memory compared to JSON according to our benchmarks.

Candidate REJECTED.

4 out of 5 interviewers had liked the candidate. I was one of the 4. He had received either above or very close to 3.0, which is a good score. The interviewer who didn't like the candidate had been at Google since early 2004. And he didn't like the candidate's joke question about whether he was very rich because he joined before Google went IPO. I guess he wasn't.

Thanks for your feedback over the last couple of months. This release addresses some of the main pain points of using Dgraph .

At Dgraph , we aim to build a low latency, distributed graph database. This means our data is distributed among nodes in the cluster. Executing a query means multiple nodes are communicating with each other. To keep our latency of communication low, we use a new form of serialization library called Flatbuffers.

In this post, we’ll look at how Dgraph performs on varying the number of nodes in the cluster, specs of the machine and load on the server to answer the ultimate question: Can it really scale?

Then there was the fact that we had so many channels and direct messages and group chats. It multiplexed my brain and left me in a constant state of anxiety, feeling that I needed to always be on guard. — Dave Teare, Curing Our Slack Addiction

I'm very excited to use this first post to talk about Dgraph , what it is and why it was created.