The option to select the engine would be good; I'd like to be able to compare the performance characteristics based on our workload; clickhouse tends to use zstd; others use zlib/gzip. The option to choose would be great.

Hi, We also need the ability to change the storage compression algorithm at the cluster level. The default algorithm set by atlas is snappy, which have bad performance in both compression rates and cpu usage compared to Zstd. Currently, in the cluster we are running on-prem, we have the ability to configure the compression algorithm in the "/etc/mongod.conf" during cluster creation in our infrastructure code (we are provisioning all our resources using IaaC, with tools like terraform, ansible, python/bash scripts), so any new collection created by application will be automatically use the compression configured at cluster level. To be more precise, the application code do not creates the collection explicitly, it just starting write to a collection. Also, the application code, which are using a collection, are distributed across number of microservices, each running a number of instances/workloads, therefore we cannot use db.createCollection option, as there is no such place, that we can ensure it will be performed once, except in infrastructure code during cluster creation, which in turn do not aware about number of connections and the collection names that will be used by application microservices.

Why is this important to you? What's driving this request?