The "1 MB message size rule of thumb" in the docs

message Locations {

  repeated  LocationArray car  = 1;

  repeated  LocationArray  boat  = 2;

}

Protobuf bytes type efficiently encodes in wire format as a length (in bytes) and a simple series of byte values, as such, it does not suffer many of the pitfalls of other large data sets. However, in proto json format, note that it is encoded into base64 and back, and thus incurs some penalties there. Best to not stuff too much into a data block. (You can always stream smaller data block pages.)

This best practice guide applies to all messages, and recursively so. In fact, embedded messages are usually even more taxing than a simple flat message, because allocations have to be done for all of the sub messages present.

If you have a very large data set and want each point to be a message, theres a number of different approaches that can be taken for the top-level-set-of-messages instead of having a single top-level message, including length-prefixed serialization (the functions named like parseDelimited), RecordIO, Riegeli, etc

Note that the true limit for what the max encoded size is 2GB, and many people do use Protobuf to serialize individual messages up to which are much larger than 1MB while still being less than 2 GB. The listed documentation is only about what Protobuf is best optimized for, where notably we don't really try to support parsing a subset of a `LocationArray` from your example; other formats would let you do parallelized parsing / mapreduce style operations over the data sets and have data sets which are much larger than 2GB.