I know that subscriptions for GraphQL are unreleased at the moment, but I’m thinking of using them from master anyway 
. My question is how scalable do you estimate those subscriptions to be?
Are there any performance hitches to be aware of when using subscriptions? Is it a bad idea to have a subscription to a large amount of data, maybe to have hundreds of thousands of subscriptions on smaller amounts of data?
Subscriptions are currently implemented by running the user-specified query at regular intervals (1 sec by default) and only returning a response to the client if the result changes. The exact throughput numbers would depend on the type of query that you are running, the amount of data returned and the compute resources that you have.
Dgraph, in general, has very good query throughput so they should be scalable. Also, to support a large scale you can always shard data and bring up more Alpha nodes.
It should be ok to have a subscription return large amount of data, but you might want to configure the polling interval. If the result of your query is changing frequently and transmitting the data over the wire takes more than a second (default polling interval) then the updates that you would be receiving might be delayed.
We are also doing some performance benchmarking in the next few weeks to test some of this stuff. We’ll share the results from those as soon as we have them.
OK, cool.
That’s what I was hoping. 
When I heard realtime response times on Terabytes of data from the readme, I figured that should be fast enough.
That would be great. 
Starting to test subscriptions. Is this polling interval set on the client side? I will admit I have not looked too far into it yet.
@amaster507 you can paas polling interval as a alpha flag --graphql_poll_interval duration . Default value is 1sec.