> "switch the app from using Postgres to Redis or Cassandra with ease" You can't. There is no such thing as switching databases "with ease" for any serious app

> "switch the app from using Postgres to Redis or Cassandra with ease" You can't. There is no such thing as switching databases "with ease" for any serious application. Postgres, Redis and Cassandra are all very different databases and it doesn't make sense to switch between them; unless your app is small and still experimental so the changes are trivial, or so large that it's a major project with very specific needs that requires far more work than a repository would solve. But if you really want to, Entity Framework already has multiple providers including non-relational databases like Cassandra. Anyone can write a provider and there are many 3rd-party libraries for whatever data source you want. > "having another abstraction layer might not be a bad idea." It's a terrible idea. It's such an exceedingly rare situation that you're wasting a lot of upfront work for something that'll never be used. Also .NET has a fantastic data system with LINQ which is built around `IQueryable` and provides powerful query modeling that can be incrementally and dynamically changed before its pushed down to the datasource. It's what makes EF so good and why repository patterns cause so many problems by breaking this interface for no productive reason. You can also use extension methods on the `DbContext` to extract complex queries or large operations to a single method. Now all that being said, there are times where you can have an abstraction/interface to your data sources if they're very complex or spread across multiple databases or have other processing needs. But at that point you actually need it, instead of just doing it as a "pattern".