Raising nofile in /etc/security/limits.conf has no effect on a systemd service. That file is read by the pam_limits module, which only runs for login sessions, and services are started by PID 1 without going through PAM. A database or proxy that hits 'too many open files' keeps hitting it no matter how high the limits.conf value goes.
The limit for a service comes from LimitNOFILE in the unit's [Service] section, or from DefaultLimitNOFILE in system.conf when the unit does not set one. Since systemd 240, released in December 2018, the default is a soft limit of 1024 with a much larger hard limit, on the reasoning that programs using select need the low soft limit and everything else should raise it itself.
Set 'LimitNOFILE=65535' in a drop-in, or the soft:hard form 'LimitNOFILE=65535:1048576'. Confirm the value that a running process actually got by reading /proc/PID/limits, which is authoritative, rather than by trusting the unit file. User services under systemd --user take DefaultLimitNOFILE from user.conf instead.