DAOFactory, is it over engineering?

I followed this article to implement DAOs for a web service: https://www.oracle.com/technetwork/java/dataaccessobject-138824.html

and I end up having following classes:

interface DAOFactory { UserDAO getUserDao();}
class MySqlDAOFactory implements DAOFactory {
   ...
   UserDAO getUserDao() {
       new MySQLUserDAO(this.connection);
   }
}
interface UserDAO { User getUser();}
class MySqlUserDAO implements UserDAO{ User getUser(){}}

This design abstracts the database implementation from client which always uses DaoFactory to access UserDAO and is decoupled from database implementation.

But does it look over-engineered in practice? The argument that I get against it is that we never plan to change the DB implementation, and this is too much code and same can be achieved using just MysqlUserDao.

Rest of the classes are abstraction layer, and if I understand this article correctly, abstraction layer is temporary : https://martinfowler.com/bliki/BranchByAbstraction.html

We may also choose to delete the abstraction layer once we no longer need it for migration.

The argument looks convincing. But the design doesn't follow SOLID design principles.

What are your thoughts on this?