The PKCE flow implies that the client application redirects the end-user to an identity provider/authorization server where the authentication and any applicable authorization is completed. For a database connection this means that the end-user inputs his credentials at the identity provider and not directly through the client application.
The client application will then just receive an assertion/token that can be used to know who is the user that just completed an authentication. This works, because a trust relationship is established between the client application and the identity provider and the assertion/token allows to validate that the token is indeed coming from the trusted party.
This flow has the great benefit that the client application does not need to directly process user credentials and as such does not need to worry in doing it in an incorrect way. However, this does mean that active authentication is performed outside of the client application, in this case, it happens as part of your account hosted login page (the
/authorize endpoint part of the PKCE flow).
You can completely customize the hosted login page, however, if what you’re aiming for was a custom user interface within the client application itself then for database connections you could consider the use of the resource owner password credentials grant. Have in mind that the use of this grant is not available by default for new clients so you’ll have to make the necessary configurations in your client grant types in order to allow it. In addition, the recommendation is indeed to use PKCE because the client application will not have to process user credentials, but if you understand the implications and you are okay with them for you particular scenario then this would be an alternative that would allow direct exchange of a username and password for tokens.