Dependency Injection with Repository Pattern or only DI?

First, pls do not tag me by assuming this as a generic global solution. My concerns are v.specific to our environment.

We're a small enterprise providing customized ASP.Net based web solutions. Mostly, it involved secure access to diff types of users to Dashboard, Managing lookup data and managing business entities as per user role, and a few other things like logging. Not much fancy stuff or complexities.

We've been upgrading from ASP.Net to MVC to webAPI and now .NET Core. We've been following 3-tier architecture (+a few utilities, libs, etc...). Now, we've been abstracting the DAL (data access) based on some "wise community suggestions" implying that such abstraction will help when we "switch" the database. But that never happened in past 7-8 years :-)

I've to raise such concerns because abstraction comes at a cost! ASP to MVC has been great, MVC to webAPI (more or less similar). But now .NET Core goes beyond all. DI / DIP, Onion Architecture, Repository pattern, ... DI looks good but then combining repository patterns seems to be over-doing.

Does a moderate level web solution need that much? MVC + KO was great! DI + Repository promises things like mocking for tests, IoC, Abstraction, ... but I can test my app using Postman and I believe we'll stick to SQL Server - so is DI + Repository good or just DI?

I don't agree DI is an anti-pattern. But then how much is too much? Any other suggestions are also welcome!