Dgraph is rapidly gaining reputation as an easy to use database to build apps upon. Many new users of Dgraph have existing relational databases that they want to migrate from. In particular, we get asked a lot about how to migrate data from MySQL to Dgraph. In this article, we present a tool that makes this migration really easy: all a user needs to do is write a small 3 lines configuration file and type in 2 commands.

In this tutorial we will build a To-Do List application using React JavaScript library and Dgraph as a backend database. We will use dgraph-js-http — a library designed to greatly simplify the life of JavaScript developers when accessing Dgraph databases. The tutorial is split into several steps: Creating a React App Starting a local Dgraph server using docker-compose Connecting to Dgraph from JavaScript and fetching data

With GDPR passing in the EU on April 14th, 2016, users on the Internet are demanding protection of their privacy and data from Internet companies. The regulation has profound implications. Many companies take the law and users’ demand seriously: they start encrypting data for traffic within their data centers, and employing strict control on who can access users’ data. The Dgraph team takes full notice of that. Access control on the data stored in Dgraph is very important to our enterprise customers.

Since writing this post, we have built Ristretto: A High Performance Go cache. Read all about it here. This post made it to the top of Golang subreddit and is trending #2 on the front page of Hacker News. Do engage in discussion there and show us love by giving us a GitHub star. Every database system requires a smart cache. That is, a cache that keeps the most frequently or recently accessed items and has a configurable memory utilization limit.

This post made it to #3 on HackerNews front page. Do engage in discussion there and show us love by giving us a GitHub star. When I introduce myself and explain what we are building at Dgraph Labs, I am typically asked if I worked at Facebook, or if what I'm building is inspired by Facebook. A lot of people know about the efforts at Facebook to serve their social graph, because they have published multiple articles about the graph infrastructure they put together.

One of the cornerstones of Dgraph is that it allows a flexible schema, which can be modified in a live system, without any downtime. This involves changing data types and adding or removing indices with a single ALTER command to match the needs of an application developer. Dgraph supports indexing natively, which means common use cases around full-text search, regular expressions, date matching, geolocation queries, etc. can all be executed within Dgraph, while maintaining transactional guarantees.

At Dgraph, we're building the most advanced graph database in the world. It does distributed transactions, low-latency arbitrary depth joins, traversals, provides synchronous replication and horizontal scalability — with a simple GraphQL-like API. Does it sounds like a tough problem? That's because it is. This blog post is about Badger, the key-value database that makes it all happen under the hood, housing all Dgraph data, including Raft logs. Badger uses an LSM tree structure for holding keys.

Last year, we had switched Dgraph license to AGPLv3.0, considering reasons like the ability to monetize in a competitive environment. In particular, The threat of duplicate commercial services and enterprise features built by others without paying anything back towards the development of the open source version. Update (Nov 2018): This post is outdated. Dgraph core is back to Apache 2.0, with no restrictions. This remains a credible threat; nothing has changed in that regard.