We’re overhauling Dgraph’s docs to make them clearer and more approachable. If you notice any issues during this transition or have suggestions, please let us know.

Dgraph client libraries allow you to run DQL transactions, queries and mutations in various programming languages.

If you are interested in clients for GraphQL endpoint, please refer to GraphQL clients section.

Go, python, Java, C# and JavaScript clients are using gRPC: protocol and Protocol Buffers (the .proto file used by Dgraph is located at api.proto).

A JavaScript client using HTTP: is also available.

It is possible to interface with Dgraph directly via gRPC or HTTP. However, if a client library exists for your language, that’s a simpler option.

For multi-node setups, predicates are assigned to the group that first sees that predicate. Dgraph also automatically moves predicate data to different groups to balance predicate distribution. This occurs automatically every 10 minutes. It is possible for clients to aid this process by communicating with all Dgraph instances. For the Go client, this means passing in one *grpc.ClientConn per Dgraph instance, or routing traffic through a load balancer. Mutations are made in a round robin fashion, resulting in a semi-random initial predicate distribution.

​
Transactions

Dgraph clients perform mutations and queries using transactions. A transaction bounds a sequence of queries and mutations that are committed by Dgraph as a single unit: that’s, on commit, either all the changes are accepted by Dgraph or none are.

A transaction always sees the database state at the moment it began, plus any changes it makes --- changes from concurrent transactions aren’t visible.

On commit, Dgraph aborts a transaction, rather than committing changes, when a conflicting, concurrently running transaction has already been committed. Two transactions conflict when both transactions:

  • write values to the same scalar predicate of the same node (e.g both attempting to set a particular node’s address predicate); or
  • write to a singular uid predicate of the same node (changes to [uid] predicates can be concurrently written); or
  • write a value that conflicts on an index for a predicate with @upsert set in the schema (see upserts).

When a transaction is aborted, all its changes are discarded. Transactions can be manually aborted.

For additional clients, see Unofficial Clients.

We’re overhauling Dgraph’s docs to make them clearer and more approachable. If you notice any issues during this transition or have suggestions, please let us know.

Dgraph client libraries allow you to run DQL transactions, queries and mutations in various programming languages.

If you are interested in clients for GraphQL endpoint, please refer to GraphQL clients section.

Go, python, Java, C# and JavaScript clients are using gRPC: protocol and Protocol Buffers (the .proto file used by Dgraph is located at api.proto).

A JavaScript client using HTTP: is also available.

It is possible to interface with Dgraph directly via gRPC or HTTP. However, if a client library exists for your language, that’s a simpler option.

For multi-node setups, predicates are assigned to the group that first sees that predicate. Dgraph also automatically moves predicate data to different groups to balance predicate distribution. This occurs automatically every 10 minutes. It is possible for clients to aid this process by communicating with all Dgraph instances. For the Go client, this means passing in one *grpc.ClientConn per Dgraph instance, or routing traffic through a load balancer. Mutations are made in a round robin fashion, resulting in a semi-random initial predicate distribution.

​
Transactions

Dgraph clients perform mutations and queries using transactions. A transaction bounds a sequence of queries and mutations that are committed by Dgraph as a single unit: that’s, on commit, either all the changes are accepted by Dgraph or none are.

A transaction always sees the database state at the moment it began, plus any changes it makes --- changes from concurrent transactions aren’t visible.

On commit, Dgraph aborts a transaction, rather than committing changes, when a conflicting, concurrently running transaction has already been committed. Two transactions conflict when both transactions:

  • write values to the same scalar predicate of the same node (e.g both attempting to set a particular node’s address predicate); or
  • write to a singular uid predicate of the same node (changes to [uid] predicates can be concurrently written); or
  • write a value that conflicts on an index for a predicate with @upsert set in the schema (see upserts).

When a transaction is aborted, all its changes are discarded. Transactions can be manually aborted.

For additional clients, see Unofficial Clients.