From the documentation:
Note that the default PubSub implementation is intended for demo purposes. It only works if you have a single instance of your server and doesn’t scale beyond a couple of connections. For production usage you’ll want to use one of the PubSub implementations backed by an external store. (e.g. Redis)
The default implementation is in memory. If a user connects to server A and you publish something on server B, the user won’t get notified because it has a websocket connection to server A. If you use something like Redis, the notification will be send to all servers.
And yes, you’ll have to call pubsub.publish() on every change you want to send to subscribers, like when you mutate something. The thing is, GraphQL subscriptions are mostly useful for events and are different than the live queries we are used to in Meteor (with meteor pub/sub). The good news is that @live queries will also come to GraphQL, preventing the need of so many manual publish calls. Read more about the current status here:
I recommend watching the mentioned video.