May 16

PQC + @defer to Stream Partial Cache Hits to the Client Immediately

Blog post's hero image

For over a year we’ve been shipping iterations of partial query caching (PQC), a feature set that leverages GraphQL’s novel structure to improve performance. Performance means different things to different people, but we’ve been building for two roles in particular: engineers and end-users (users). We’ve already shipped big wins for developers with PQC, but it only benefited users in specific scenarios. Today, we’re introducing native support for PQC + @defer so that everyone wins.

Refresher: what makes GraphQL unique

A unique selling point for GraphQL is the ability to explicitly request only the data you need. On a webpage, for instance, you can request just the data required to render the page. Though you can recreate this pattern with other protocols, it is a first-class concept in GraphQL.

It’s great that all of your data can be fetched in a single request, but it also means that different data domains become co-mingled. Historically this often made GraphQL requests uncacheable because things like user-specific data or real-time data are present in most requests. Luckily, we shipped PQC back in February to mitigate this issue.

PQC has been a win for engineers

When we moved partial query caching (PQC) to GA, it was a huge win for engineers. Origin infrastructure only had to respond to a subset of the original client query without having to split queries into cacheable and uncacheable. This can greatly reduce origin load and cost, especially in scenarios where only a small subset of a query is uncacheable. However, if the portion fetched from the origin was slow, users did not see any benefit from PQC.

PQC + @defer is a win for users

Starting today, you can immediately return cached content to the client and use @defer to return uncacheable content when it’s resolved by the origin. This experimental features introduces the ability to instantly display cached content to the user, greatly reducing the time it takes to display essential data. Better yet, all you need to do is wrap the uncacheable fields in @defer and ensure you’re using a defer-compatible server - we’ll handle the rest.

query ProductWithAvailability ($id: ID!) {
product(id: $id) {
... on Product @defer {
availability {

Let’s put it to use

With PQC + @defer, you can now reduce the origin load, save money, and improve your user experience. You can opt-in to PQC + @defer in your Stellate config by setting partialQueryCaching.experimentalDeferSupport to true. We consider the feature to be experimental - we’re excited about what we’ve built, but won’t transition it GA until we’ve seen more use in the wild. Have a use case you’d like to discuss with us? We’d love to talk about it - please reach out to and we can dig in. You can also head over to our docs to learn more.