There is a lot of topics on using Apollo server or any other stitching framework techniques in top of graqhQL APIs.

I believe taking a different approach might be most of the time better using DB replication

If you design and slice your architecture components (graphs) into modular business-domain units. And you delimit each of them with a db schema.

You can effectively use tools like Entity Framework, hibernate, etc to merge each db schema into a readonly replica.

Stitching approach has its own advantages and use cases same as db replication. Although, It is common to find a lot of articles talking about stitching but not much about database replication.

Db replication, might pose some challenges specially in legacy architectures. But I think the effort will outpace the outcome.

About performance, you can always spin up multiple replicas based on demand, cache, etc.

There is a delay in the replication but I find this a trade off rather than a limitation (depending on the use case)

When talking about caching or keeping the state in top of the graphs it might be useful into an extend.

In the real world you will have multiple processes writing into the main database via different ways. e.g Kafka events.

It’s a challenge to keep up with these changes doing a cache in top of the graphs. Also N+1 problems will be faced in complex GraphQL stitching queries.

What is your experiences on GraphQL in the enterprise world. I also found challenges implementing a large graph API.

But that’s a different topic