As far as the InnoDB storage engine is concerned, the data files are supposed to be compatible between scalar register files of different width (32-bit or 64-bit) or byte order (big endian or little endian).

However, there is a design bug in the InnoDB FULLTEXT INDEX implementation, in the encoding of the inverted index. That code destroys the portability of InnoDB FULLTEXT INDEX between different byte orders. In the function fts_fetch_index_words() you can find a FIXME comment about this.

In MySQL 5.6, MariaDB 10.0 and MariaDB 10.1 there was a bug in innodb_checksum_algorithm=crc32 that only affected big-endian ISAs. In MySQL 5.7, that bug was fixed and a compatibility work-around for that was introduced, to allow data files to be portable between (say) SPARC and AMD64. Because that compatibility work-around would weaken the page checksums further, it was removed in MDEV-17958.

On https://buildbot.mariadb.org we have two big endian builders: IBM AIX running on IBM POWER in big endian mode and GNU/Linux running on IBM System Z (s390x). While ARM and POWER processors have traditionally been bi-endian, my understanding is that GNU/Linux distributions nowadays prefer little endian when the option is available. I have also understood that in ARMv8, the big endian mode has been made optional.

I cannot say anything about the compatibility of other than InnoDB files, such as .frm files. I do not think that we regularly run any portability tests between processor platforms. The checksum algorithms (two variants of CRC-32; see MDEV-27208) are covered in our regression tests.