I think approach depends heavily on several factors:
1. Will languages/technologies used for API, UI and DB testing be the same?
If yes, I prefer creating one project with API, UI and DB clients. In that case, you will be able to use API methods (that are usually faster, than UI ones) to place the system under test in a specific state and only after that use UI client to check UI part. Also, it allows not only to test database by itself but also use DB client to validate that changes made in UI/API are properly propagated to database. So, end-to-end scenarios can be covered better using this approach.
However, if it is better to test UI using special tools (in case of JS or Spring-based UI) that are not supported by your language of choice for backend testing, it might be beneficial to separate repositories for frontend and backend testing.
2. Will testing methodologies applied to frontend and backend testing be the same?
For instance, if you would like to use Behavior Driven Testing (BDT) for frontend, you might want to separate UI and API testing repositories in order not to think about wrappers for running different tests and make the test code more readable by not mixing the paradigms.