This is an interesting an complex topic.

Kenton does a pretty good job discussing this here https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-...

and rightly mostly focuses on the message-encoding aspects. Performance will vary by use-case & platform and should be traded off against the suitability for the given use-case (platform support, schema evolution, fidelity of representation, maturity vs bleeding edge)

Cap'N'Proto has some interesting RPC features (promise-pipelining, pass-by-reference) that may be valuable to some.

FYI it would be perfectly reasonable to use Cap'N'Proto messages with GRPC as the transport layer to get HTTP2 support. GRPC was explicitly designed to allow for this.

Protobuf has better platform coverage than FlatBuffers and it's schema is easier to evolve but neither of these may matter for your use-case. As in all things it depends.

GRPC looks a lot like Google's internal Stubby, which is the main thing I am thinking of when I say "traditional RPC system" on this page:

https://capnproto.org/rpc.html

Same here but i'm also curious how the new version of Protocol Buffers compares to Flat Buffers that Google released a few months ago. The flat buffers documentation explains fairly well why i should use that but why should i use protocol buffers instead of either Capn'Proto or Flat Buffers?