Ok, I bring this up only because SQLAlchemy supports the format dialect+driver and uses postgresql+asyncpg throughout documentation, and since I'm using SQLAlchemy elsewhere in a project I can't reuse that URL with Databases (since postgresql+asyncpg raises a KeyError).

More background: I'm writing a FastAPI project and using fastapi-users which requires Databases. So I'm stuck having to supply a DB URL to both libraries. Ideally these should be able to be the same, and since one's built on the other, they shouldn't act differently anyway.

If it's not ok to have multiple mappings for a backend (i.e. specifying all valid schemes), I propose the following strategy:

1. check to see if the complete scheme is supported
2. otherwise check if the dialect is supported, use that backend and ignore the driver if specified

I agree that making it specific dialect+driver looks better. But as you said if we could handle both cases it would be great for backwards-compatibility too.
This just needs the missing test coverage, and we can merge it.