It all depends on how your application is structured. Problems may arise due to access security implemented in Java Classloaders.
If your application manages the connection to the database, there are no problems leaving the JDBC driver in your lib, as the classes will be managed by the same Classloader.
However, if you leave the connections to the application server, the driver needs to be in the server lib, as the classes present in this lib will be managed by another Classloader.
Note that when we speak in a complex environment of a JVM, composed of several Classloaders, many things that are true and simple in a common Java program become false and difficult.
For example, when there are multiple Classloaders, there is the possibility of having multiple copies of the same class in memory, whose static attributes may contain different values for each Classloader. This causes many problems.
In addition, each container mounts a Classloaders Hierarchy to protect its own libraries from misconceptions and attacks from a third-party application and also to prevent one application from interfering with the other. This, for example, allows multiple instances of the same application to be "installed" in the same container instance.
Take as an example the Tomcat Hierarchy of Classloaders:
Bootstrap
|
System
|
Common
/ \
Catalina Shared
/ \
Webapp1 Webapp2 ...
When a Java program first uses or imports a class, the current Classloader queries its higher-level ancestors in the hierarchy. In the case of Tomcat, if an application will load the class Pessoa, her classloader first checks in Shared, which in turn checks the Commom, which in turn checks the System. If the class does not exist in the "parent" Classloader, then the current Classloader tries to load the class and returns a positive or negative response to the "child" Classloader, culminating in a cascading process.
A common problem is putting a framework like Spring in lib Shared. When the application starts Spring, it is then found in Classloader Shared. However, Spring will attempt to load multiple configured classes into XML. When it prompts your Classloader (Shared) to load the class Pessoa, the Classloader nay will look for the class in the Classloader "son", ie the Classloader of the application, just where the class is.
These rules are not exactly rigid, there are settings that allow you to change the behavior of Classloader. There’s no need to be afraid of them, they’re just Java classes with specific implementations and logics. The important thing is to understand how they work.