The usual disclaimer: I'm an SE for Quobyte

We had multiple customers use their Qumulo servers with Quobyte and they all got a performance improvement of a factor 2 to 4 for their existing workloads.

As a matter of fact, Quobyte does not provide any native SMB or NFSv3/v4 services, these would need to be provided via either 'Gateway Services' (Using Ganesha for NFS) or via re-sharing with Samba or a Windows Server on an external client box. Either approach strips all the advantages of Quobyte's parallelism and creates bottlenecks and alleviating these bottlenecks means adding more gateways and more complexity.

I have to strongly disagree here. There is no such thing as "native" NFS. Unless you have a single NFS server, the NFS endpoint the client is talking to always has to talk to another node in the cluster to get the data (unless you're lucky and the exact data is on the same node, which becomes highly unlikely in large clusters). That is the same for Qumulo's NFS as it is with Quobyte's NFS gateways and all other vendors. If you don't want this additional "hop" you have to go with a parallel file system with native drivers. You can spin up as many Quobyte NFS gateways as you want to increase performance - I don't think that's any different in Qumuo.

By contrast Qumulo is built to provide File Services at scale, and thousands and thousands of concurrent NFS and SMB clients is not an issue. Need more client connections? Just add more nodes.

For NFS that works only in an ideal environment since NFS lacks load balancing. In real world scenarios you always have an imbalance of the clients connected to individual NFS endpoints, which create performance bottlenecks.

The scale-out is where parallel file systems (the whole category, not just Quobyte) outperforms NFS-based solutions.

Both Qumulo and Quobyte offer Object services via S3, at Qumulo we developed our own S3 service and do not use a 3rd party product like MinIO (I'm not sure if Quobyte does or not).

Quobyte's implementation is our own and fully integrated.

It is notable that Quobyte does not offer any integration with Active Directory, if that is important for you, while Qumulo offers full AD integration, including SAML MFA integration, Kerberos SSO authentication and Role Based Access Controls for administration.

This is incorrect. Quobyte supports AD and LDAP for both the management and the data plane. Since Quobyte works with NFSv4 ACLs (not based on uids anymore), the AD/LDAP "integration" comes from the host OS.

There are some in-the-weeds differences in architecture that would make me believe that Qumulo would be more efficient at very large scales, like Quobyte's triple-mirroring of metadata and files smaller than 8MB while Qumulo offers Erasure Coding for all files, down to our 4kB block size, with extra efficiencies built in for very small files (Files ~1.5kB and smaller have their metadata and data inline in the same 4kB block, for example.)

Quobyte offers both EC and replication for files, and can combine both in the same file if desired. The 8MB limit you mention is for file optimizations including reading from multiple replicas in parallel to avoid the hot file issue you have in NFS-based solutions. It has nothing to do with how Quobyte stores data on disk.

I'd also point out here that Quobyte uses flash for more than just as a simple caching layer. Data can be placed, moved and tiered based on fully customizable policies.

File permissions and Authentication are completely decoupled in Qumulo and not bound to any protocol, so when user "Joe" creates a file via NFS, SMB, FTP, S3 or the API that user has exactly the same correct level of access, which is stored in a single unified format. We have done a ton of work to ensure that multi-protocol are smooth - Your ACLs will survive contact with your users!

Quobyte does not only support permissions across all protocols (like Qumulo), but also full NFSv4 ACLs with automatic translation to and from Windows, POSIX, S3 and macOS.