The test pyramid is a lie...
The concept of the testing pyramid is easy. The idea is that you want to do most of the testing at the unit test level, and a few of your tests at the integration level, and even fewer tests at the end to end level. Well this is a strange representation of testing...
While I can kind of appreciate what it is trying to preach, testing isn't like your nutritional pyramid... You don't have to eat a crap ton of unittests, some integration tests, and a little bit of end-to-end test to stay healthy...... Nah, you can can just gorge yourself on that sweet end-to-end test and your software would run just as good.
It's all about that test calories my friends... some people call it test coverage. Whatever you call it, the name of the game is to get your daily intake of test calories. Because calories are all the same, Do yourself a favor... Eat whatever gives you the highest amount of calories and for the lowest amount of work.
I recently worked on a project where it took me longer to fix some of the unit-tests than the actual application. When that is the case, you know something is not right. Unit tests are meant to be simple. It's a common trap where people try to emulate a database or a down stream service in their unit tests. Look, there is nothing (besides this pyramid?) that says you must have more unit tests than end-to-end tests.
End-to-end does not necessary have to be more time consuming than unit tests. logically, end-to-end tests can provide all the coverage that unit tests can provide and more. Conversely, unit tests cannot provide all the coverage that end to end testing can provide. unit tests can get close with some imagination. A rule of thumb is that the closer the unit tests get to integration or end to end functionalities, the more work is required to write the unit tests. Vice versa, if you're leveraging end to end to test every condition of a function, you're going to have a bad time.
Furthermore, the different levels of testing can have overlaps. If there is the luxury of having the different levels of testing, then optics should be adjusted as to not duplicate efforts when it comes to testing. Meaning, if your end to end test is already covering the common paths of your application, why write unit tests to cover those cases again? At the end of the day, testing is a mean of ensuring quality software. If all your bases are covered, does it matter what kind of testing you're doing?
TLDR. The test pyramid a a baffling idea. Do yourself a favor and forget about it. Keep unit tests simple, and write the kind of tests that the provide the most coverage for the least amount of work.