Who’s new in June 2020

I think sometimes it can be a bit unnerving to join a new community and not know what all the rules and regulations are. Don’t be shy. If you’re new here, feel free to say Hi and introduce yourself to the community on this thread.



I am new to dgraph.
I like dgraph very much,but at the same time confused . dgraph’s documentation is so bad that I need to spend a lot of time to explore it, and then the API of dgraph is very difficult to use, I even have the idea of giving up dgraph. :expressionless:


Hello! We are sorry to hear that. We’re in the process of improving our docs, and it will take us a few weeks, so your patience is appreciated. If you have any specific questions that is blocking you from using Dgraph, please ask away here. Our Dgraph team and the community will do the best help!


Hi everyone :wave:

I’m new here, glad to be joining the community! I’m currently trying out Slash GraphQL’s beta and I really like it so far. While playing with it I came up with these questions:

  • What happens to redundant data after a schema change? I just tried removing a ‘username’ field on my User object and added it back in after that. The username values I created pre schema change were still there. Shouldn’t they have been removed? Does that mean that if my schema changes often that I accumulate a lot of redundant data that just takes up storage?
  • is there some way to view my whole graph at once with Slash GraphQL? I remember ratel having a nice graph visual inspector when I tried it out a couple of months ago.
  • and finally, a more specific question to an issue I ran into, where I have this query result:
  "data": {
    "queryUser": [
        "name": null,
        "username": null
  "extensions": {
    "touched_uids": 3,
    "queryCost": 1

does the ‘touched_uids’ mean that there are 3 user nodes in my database? If all three of these nodes don’t have a value for their @id field and all of their other values are null, is there any way I can get ahold of these nodes to delete them properly?

I purposely created this scenario, by

  1. creating three users, where the username field had the @id directive
  2. updating the schema by adding an email field with the @id directive, removing the @id directive from the username field
  3. Emptying all other fields, e.g. like so:
    mutation UpdateUser { updateUser(input: {filter: {username: {alloftext: "max"}}, remove: {username: "max"}}) { numUids } }

Probably unlikely that I’d ever do this in reality, but I’m just trying out edge cases to build understanding and confidence using dgraph.

And a quick tip for others trying out the beta: If you need more guidance on how to do schema migrations (in addition to just using the schema docs), Michael demonstrates one here in this twitch stream: https://www.twitch.tv/videos/632933722?t=00h53m52s.


I think it would not be safe to delete data through Schema changes. The most correct way is for the user to perform a deletion procedure. Thus, we are sure that the deletion is intentional.

For now, I think that there is no way to do this directly in Slash GraphQL. But it is in the roadmap to expose some operations.

There are two ways to do this in Dgraph.

    • Via alter operation
curl -X POST localhost:8080/alter -d '{"drop_attr": "username"}'

This will exclude only “username” from all nodes that have this predicate.

For the moment it is not possible to use Upsert Block in GraphQL. But soon you will be able to run GraphQL+- using the @custom directive.

In the roadmap, there is an intention to support GraphQL queries in the Ratel.

Nope, it means the query cost 3 units. This value is used to determine the use of credits in Slash. The more complex the query is, the more UIDs it will touch.

I don’t think I understand, I’ll call our wizard @michaelcompton.

This link has changed. Twitch has a policy about keeping the footage. The default is 16 days.
Apollo has uploaded it to their YT channel



@akashjain971 and @abhimanyusinghgaur can add more.

But I think this is not exposed to users in Slash GraphQL right now. Only /graphql endpoint is exposed.

Agree with @MichelDiz that touched_uids name is misleading. This number essentially means number of nodes + edges traversed. So if your graph has 3 nodes with fields name and username. And you query all nodes and all fields, touched_uids should be 6 since you traversed 3 nodes and 2 edges on each node.


Hi, I am Thomas, a backend developer from the Netherlands. I am working on a PoC for a large government project. I choose DGraph because of it’s horizontal scaling capabilities, it’s nice (Golang) Api and it’s “freshness” :slight_smile:

My experience so far working with DGraph has been quite pleasant. I especially appreciate the quality of the documentation and of the tutorials and examples.

I look forward to working with you all!


Hey @mvcatsifma,
Welcome to Dgraph, glad to know that you like the documentation. Feel free to post any issue that you face.

@id directive enforces uniqueness constraints on the values. The @id field can be added only to non-nullable fields. It uses @upsert from GraphQL± to achieve that. If you are adding @id directive on an existing field with unique values and non-null values, it will continue to work fine.

If we somehow assume that you end up in the situation mentioned above, you could probably expose the internal dgraph.xid, and then if you queryUser, it will return all users, and then you can delete User nodes by xid.

type User {
        id: ID!
        email: String! @id
        username: String! @search(by: [hash])

Query to get all users.

query {
  queryUser {
1 Like

yep, as I said

For now, I think that there is no way to do this directly in Slash GraphQL. But it is in the roadmap to expose some operations.


1 Like

:wave: Greetings from Silicon Valley! :wave:

I’m a technology entrepreneur and (go, python, ruby) developer using dgraph in a project to help people get back to work post pandemic.

Being new to graphs, I’m trying to figure out the role of a SQL store in support of our graph for our specific use case. It seems like the right idea but I’m so hard wired to SQL I’m unsure. :thinking: :man_shrugging:

As I start to wrap my head around this concept:

  1. We should keep a dgraph UUID in our entity tables with a unique index.
  2. Anything else on each graph entity? Type?

I welcome your inputs and advice on this SQL/graph hybrid architecture. :pray:

Speaking of SQL, I’ll be doing a very non-trivial SQL migration and will post questions, findings, etc, elsewhere in these forums.

Super glad to be a new part of this great community!

John Knapp


That’s nice.

Not sure If I got, Is your intention to keep two DBs in sync? That seems like a lot of work. As Dgraph is a GraphDB, it can be hard to sync it with a SQL DB. It is possible but feels hard.

It seems to me that you want to keep Dgraph as the main source of truth. And SQL as a copy? have a specific reason? And Yeah, some strategy with UID would be a nice way to deal with Dgraph.

How do you intend to use SQL in conjunction with Dgraph?

Take this read https://dgraph.io/blog/post/migrating-from-sql-to-dgraph/ can be useful.


Thanks Michel for the substantive reply, and kind words.

I recall reading in certain cases it makes sense to keep relations in a graph and entities in a RDBMS. We need to get deeper into our use cases to know if that’s right in our case.

What I do know is we’re going to have a bunch of entities and relations. Our source DB has 24+ tables, 70+ FKs and well over 1MM rows.

Thanks for the link, I already read that and eyeballed the migrator code a bit. I’ll get set up and type dgraph migrate ... in the morning. I’m sure it’ll be an interesting day! :slight_smile:


Hi Team,

I am new to Dgraph!

I stumbled upon this amazing tech by chance, and I am so glad I did.

This is the first time I am interacting with a community.

Prior to Dgraph, I was looking at Postgres + Postgis + Citus + GraphQL Server.

I found out that Dgraph does everything the above tech & their paid version can do collectively, and on top of that, it has full spec compliance, shard rebalancing, encryption at rest, Snappy as compression, inbuilt caching, … And all of that in the free version, Damnn!!

It really is the world’s most advanced GraphDB.

I am figuring out every inch of this tech one by one.

As of now I can run a local Swarm, connect to it via Postwoman, GraphQLPlayground, & Ratel. have followed along with the Twitter Clone YouTube vdo, gone through GraphQL documentation in the website.

Also learnt a bit of Graphql ±, the whole Graphql Schema, and a fraction of RDF.

And now I am confused as to:

  1. How many concurrent mutations & queries this DB can handle?
  2. How do I do Spatial queries in Graphql and not the old way or RDF?
  3. What about TimeSeries data?
  4. Why old Docs don’t say that there is a new way of doing things, like “don’t read this if you are starting new”? (As I followed along GraphQL ± before discovering the full spec compliance of GraphQL)
  5. Dgraph Docs vs GraphQL Docs, differences?
  6. How to archive older data, so that they just become read-only?
  7. What is the use case of having data attached to connections between nodes, and is it possible in the new approach, i.e. GraphQL native approach?
  8. How to do a file upload, do we write a separate server which will handle the storage & mutate Dgraph with file URL? (Is custom resolver going to help?)
  9. Why Rust wasn’t used? (Because of Long Compile Time or Immature tech at the time of making or long on boarding time for an inexperienced developer or something else)


  1. A node visualiser for pure GraphQL, as it’s in Ratel for GraphQL±. Both QL are a bit different, and writing twice, once for actual query in GraphQL & once for visualisation in Ratel is a bit daunting.
    Will Ratel get an update with said feature?

Yeah. When dgraph was born, rust was not yet mature.
I also look forward to the rust version of dgraph, which will bring very good performance and security.
I hope team can consider rust.

Hey Abhijit,

I’ll let someone from the team answer all your questions. But just want to chime in. If you’re looking for Dgraph’s GraphQL, then you should consider https://dgraph.io/slash-graphql .

1 Like

Hi Manish,

Thank you for a reply. Down the road I will definitely consider a managed service!

As of now I am trying to learn as much as I can, to impress interviewers and maybe have a wonderful website along the way while standing on shoulders of giants.

1 Like


This depends on the resources you have. Personally I never thought of track this, maybe we should start doing this in benchmarks. You can check out this guy bench https://github.com/linuxerwang/dgraph-bench and in our blog we have some benchmarks too https://dgraph.io/blog/ e.g https://dgraph.io/blog/post/bulkloader/

You can also test with ludicrous mode, and you gonna have astonishing results.

For now, GraphQL don’t support Geo-Spatial queries. You can read this RFC RFC: Implementing Geo features in GraphQL

Dgraph wasn’t designed for that.

Not sure what is the point of the question. The docs should say what and where? Your example is the answer?

If you are starting to learn Dgraph you should take our Tour https://dgraph.io/tour/

The only difference is implicit. One is focused on GraphQL only, the other on Dgraph’s features, operations, and so on.

Not possible, you can make the whole server read-only tho.

Not sure If I got the question. Maybe the answer is https://graphql.dgraph.io/dgraph. If not so, please clarify. BTW, as GraphQL+- is inspired in GraphQL, almost everything is similar between them.

In general, yes, you should handle this with a storage service. You can use https://graphql.dgraph.io/custom/ to do this.

I think so, it Is hard to find good Go Dev, so imagine how hard it is to find Rust dev. Today maybe it is different.

It is in Ratel’s roadmap to support GraphQL queries.



I do think we can be more clear there. Most users would be happy with GraphQL, and that should become the entry into Dgraph. For advanced users, they would want the power that comes with GraphQL± and transactions and so on. By being clear about these differences, our users can have a better experience.

This might also be a good time to switch the naming to DQL from GraphQL± .