Releasing Dgraph v1.1.0

Dgraph is an open-source, transactional, distributed, native graph database. Ever since the internet explosion, the data not just has been growing in size, but also in its complexity and connectedness. Dgraph is built as an effort to enable and simplify the development of scalable cloud applications that could continue to thrive even when the data is highly connected and involved.

Set on this path, embracing open source all along the way, the first production-ready, major release v1.0.0 happened in December 2017. Since then, the feedback from the community and customers has prominently shaped the evolution of the product. Thanks to all of you!

Also, along the way, we have hit a few major milestones. Raising Series A funding and Reaching 10K starts tops the list.

Dgraph’s new release v1.1.0 is here. The new version ships with a plethora of significant changes and new features. In this post, we will cover the most important ones, but you can find all the details in the changelog.

Breaking changes

Before we go over the new features, let’s cover the changes that could break your current code. We have only four breaking changes, so you might probably want to have a quick look at them.

1. Removal of _predicate_ keyword

Due to long-standing performance and transactional concerns around _predicate_, the keyword has been removed in this release.

We are working on providing an alternative mechanism to support our users while writing their queries. If you have specific needs or suggestions regarding this feature, please let us know by filing an issue on GitHub.

2. Change in behavior of * in delete operations

The delete operation with * only deletes the predicates which are part of the types associated with a given node. For instance, let’s imagine we have a node with UID 0x1 of type Person.

type Person {
    name: string
    age: int
}

To this node of type Person, we associate an extra predicate salary of type int. Running a delete operation with wildcards would delete the name and age predicates, but not the salary predicate.

delete {
    <0x1> * * .
}

As a logical consequence, running a delete operation with * on a node with no types would not delete anything. This change is tied to the removal of _predicate_ mentioned above.

3. Predicates of type UID lists are now explicit

Before this release, it was not possible to say that a predicate could have a single UID value. This was caused by foo: uid . being interpreted as a predicate foo of type list of UIDs.

In the new release, to indicate that a predicate has a list of UIDs associated with it you will need to use [uid], as uid now means the value is a single UID.

4. HTTP header changes

We have dropped support for the HTTP headers X-Dgraph-CommitNow and X-Dgraph-MutationType. Instead of X-Dgraph-MutationType, we now use the standard HTTP header Content-Type, and X-Dgraph-CommitNow is now a query parameter in the URL commitNow=true.

This should only affect applications that are directly using Dgraph’s REST endpoints. If you are using a client library, these changes should be fully transparent.

New Features

Now that we have covered the breaking changes, it’s time to go over the exciting new features which are coming with v1.1.0.

A new type system

Starting with version 1.1.0, Dgraph provides support for types. Types allow grouping of nodes into sets describing the data associated with them.

The type system follows the GraphQL syntax for defining the types. The fields in the types correspond to existing predicates in the schema, where their indexes are also defined.

type Student {
  name: string
  dob: datetime
  home_address: string
  year: int
}

This type system is an early release and, among other features, doesn’t support required (aka non-nullable) fields. Defining a field of type string! is supported but it will be considered exactly as string for now.

Once a type has been defined, nodes can be given associated with the dgraph.type predicate. The new type function can be used in queries and filters to find the corresponding nodes. Here are the docs to learn more about the type system in Dgraph.

Upsert blocks

Dgraph doesn’t have the concept of primary key. The upsert primitive is necessary to guarantee the uniqueness of the value for a predicate (like the email of a user),

Previously to this release, upsert was a two-step operation:

  1. First, send a query to find whether a user exists with a given email.
  2. Then, if no user was found with that email, use a mutation to create it.

With the new upsert block feature, upserts can be performed in one step. This simplifies the usage of client libraries to build applications, improves the performance by reducing the network calls, and enhances the developer experience around upserts.

Here is the commit on our flock project (a twitter clone build on Dgraph using Go) which illustrates the simplicity the new upsert block brings into application development on Dgraph.

Here are the docs to learn how to use upsert blocks.

Enterprise features

Binary Backups

Binary backups are part of Dgraph’s enterprise features. Backup can be stored directly on your on-premise or cloud storage systems and then they can be used to restore a new Dgraph cluster to the previous state.

You can learn more about Binary Backups reading the Binary Backup documentation page.

Access Control Lists

Access Control Lists (ACL) provide access protection to your data stored in Dgraph. When the ACL feature is turned on, a client must authenticate with a username and password before executing any transactions and is only allowed to access the data permitted by the ACL rules.

Check out the docs to learn more about ACLs.

Ready to migrate?

If you are convinced that v1.1.0 is the future and you are ready to migrate, make sure you follow these steps.

First, export the data from your current Dgraph cluster following the database export documentation. Make sure you keep this data somewhere safe, you will need it soon.

Then, install v1.1.0 and either follow the bulk loader documentation to import all the data back into the database before it starts serving traffic, or start your new cluster and use live loader.

Please, note that the UIDs will change during the export/import process, so any queries or mutations using explicit UIDs will fail. We recommend using upsert mutations instead. In future versions, UIDs will be preserved during the import/export process.

In conclusion

We went through the highlights of the release including the new features and four breaking changes. To know more about all the changes, bug-fixes, and enhancements this release is shipped with, read the changelog.

This release is the result of years of evolution driven by the feedback from the community and our customers. We’d like to take this opportunity to thank you all again for helping us make Dgraph even better with every release.