Neither. What you need is a file system, or cloud blob storage. Choose one with high compression ratios.
Typically data is used intensely for a short while then touched only infrequently thereafter. Choosing a storage service with tiers will allow further cost saving.
As the service becomes popular it is likely several users will have the same dataset. Storage service de-duplication could allow further cost reduction.
Store the meta data in whichever flavour of DBMS you choose for the main application. This will reduce the overall complexity and utilise existing expertise. Relational would be my preference but document storage would work, too.
MongoDB adds empty space to the written data so the on-disk length follows a power-of-two rule. This could waste a lot of space depending on how your source JSON works out. This is a lot like the fill-factor in RDBMS B-Tree indexes. This behaviour can be removed in more recent versions.
Performance-wise I would think a solution based on the file system directly would be marginally faster than one involving a DBMS of either flavour. Both approaches will use the same underlying hardware - spindles, NICs, buses etc. The DBMS, no matter how efficient, is an additional layer in the stack between the disk and the client. If it is not adding additional value, through joins, filters, aggregates, security or whatever, I can't see how having it in the run-time path helps. The meta-data is a different beast to the JSON, of course, and will benefit from all the additional functionality a DBMS provides.
There's a trade-off to be had with compressed data. On one side the storage IO and network communication is faster when the data is compressed. Reading 10GB uncompressed data from disk and moving it over the network will always be slower than reading and moving the same data compressed to 7GB. On the other side is the CPU cost to decompress before usage. My experience from data warehouse environments, with gigabyte-scale reads and ten-plus cores, is that compression lowered elapsed time. In OLTP-like environments (small, random reads with frequent updates) compression is definitely not recommended. We don't have hardware specs, dataset sizes, usage patterns, pricing information or a measure of your speed-versus-cost tolerance so can't calculate this on your behalf. Likely testing at production scale will be the only way to answer this properly.