I did quite a lot of tests with multiple databases during the last months and found out that this statement might indirectly be wrong respectively that under certain conditions it be couterproductive to have swap.

Meaning that on a server with a total of 32GB RAM, and 4GBs of really used RAM (for the executables of the DBs and some directly cached data, while I left the rest free to be used for the usual filesystem cache), and when doing a lot of I/O to&from disk for hours up to days, Linux started swapping tiny amounts of KBs quite early and kept on doing that for a loooong time (probably until it doesn't find "unused" execs & other stuff in RAM which is idle).
My workaround was to set swappiness to 0, but that's for sure not ideal... .

Summarized: the kernel might try to use swap even if there is plenty of "unused" RAM, with the scope to increase the available RAM to be used for filesystem read-cache, if there is a lot of I/O.
If under this condition a program is running which becomes active only rarely, having swap will slow down its execution (because when it executes it will probably be swapped out).

Correct. mkswap

So used to fs after all the "other" tools.

And perhaps override defaults to not favor using swap.

# echo 20 > /proc/sys/vm/swappiness

The default is 60 for many distros. Which can slow you down for things like gaming where playing it safe isn't much of a concern.

I guess it must have been a while since I needed to add swap on the fly. Thank you.