Okapi and probably all modules are using legacy (though still supported) postgres libraries, which have major drawbacks and sometimes seem to be not correctly implemented anyway.

• Migration to PG10+ will be mandatory in September 2021, because that's when support for 9.x will be dropped after 5 years of maintenance. Pushing that to the back of the queue will be stressful for the community afterwards, when the deadline draws near, especially with more and more modules being build on legacy functions and more libraries using folio in their production environment.

• SSL not supported
  Okapi 2.36.0 is not able to talk to a PG server that enforces SSL communication. Although a dedicated VLAN can be used for communication of this type, a single error or bug in the network setup can severely impact query privacy in this scenario, including exposure of database (login) information to a sniffing attacker. Defense in depth -> use everything that secures confidentiality and security of communication and hampers a potential adversary, so even crushing 0day exploits are highly unlikely to compromise the setup.

• MD5 mandatory
  MD5 is the only password storage hashing algorithm that is supported by PG 9.x. And it's legacy, i. e. broken beyond repair and hope. PG 10 introduced SCRAM-SHA-256. Not only is sha256 a stronger and - for the foreseeable future - secure hashing algorithm, it also is salted and bundled with salted challenge response authentication, which doesn't expose passwords to sniffing parties on the network. Even if database breaches are something that seems like a worst case scenario, exposing passwords due to weak hashes during a breach will put a lot of users under fire, since we all know a lot of people recycle their passwords. SCRAM-SHA-256 won't be breakable for quite some time (as of current knowledge), and the salting counters rainbow table attacks too.
  There also is the problem that MD5 hashed passwords are incompatible with SCRAM-SHA-256 authentication, so upgrading and using the better algorithm is only possible by resetting all passwords, which is a nightmare in its own right.

Additional note: Enable SSL server certificate pinning when upgrading

postgresql will by default allow connections to servers with unknown/self-signed certificates and doesn't bother about server verification:
https://www.postgresql.org/docs/current/libpq-ssl.html#LIBQ-SSL-CERTIFICATES
Introduce a parameter to make certificate verification enforceable or better make it mandatory.