The disk space footprint is determined by the way columns are being stored. MonetDB uses dictionary encoding for string and blob columns, but aside from this there is no default compression applied to reduce the disk footprint. The prime reason being the two-headed sword of compression. On the one side it saves (cheap) disk space and IO bandwidth, at the other side it adds cost of expensive CPU (de)compression overhead (see compression). Since all column data in MonetDB are memory mapped upon access, they do not need to be decompressed, saving CPU time.
If disk space comes at a premium and memory residency can be guaranteed for a long time, then a compressed file system, e.g. BTRFS Compression, may become helpful. Its compression behavior is often as good as dedicated algorithms executed within the critical path of a query execution.
Tip The disk footprint can be assessed using the (Linux) command du -h on the dbfarm directory
or to run the SQL query select * from storage(), (see storage model).
One of the features of MonetDB's execution model is that all intermediates can be materialized as memory mapped files. A consequence of this approach is that when memory is too small to keep them around, they will be swapped to disk by the operating system. This can be seen as a decaying free disk space and ultimately a full disk. In turn this (should) lead to a single transaction abort and removing its disk claim. Evidently, filling your disk depends on the number of users and the complexity of their queries. It aids to the cost of running COPY INTO and queries concurrently.
If you have limited resources for concurrent access then the monetdb funnel may be an option to serialize the user requests. A single server can have multiple funnels.