By interface do you mean an OOP style interface as in the C# (and I think Java, been many years since I touched Java) keyword? Or do you mean some sort of inter

By interface do you mean an OOP style interface as in the C# (and I think Java, been many years since I touched Java) keyword? Or do you mean some sort of intermediary 'wrapper' code rather than calling the API directly? The latter I think can have value even if you only have one implementation as it makes it easier to find and update all the places that touch the underlying API in case you ever do need to change. It can also give a clear picture of the surface area of the API you're actually using all in one place in the codebase. The former I think is less valuable and often a bad idea. As others have pointed out, unless you actively maintain and test multiple implementations there is little chance you will actually be able to effectively abstract across them and just drop in a new API / 'backend'. You will end up having to rewrite and refactor code that uses your interface anyway to actually swap to or offer an alternative. At that point a C# or Java style interface isn't buying you much and is just adding complexity and code duplication (and potentially impacting performance). The calculus may look slightly different for internal projects that your team fully controls (where there is less value in an interface) vs. open source projects that want to make modification easier for others (where there might be more value). The examples you give of projects like Ghost dropping support for alternative databases I think reflect the reality though that if you're not actively maintaining and testing multiple implementations (which is extra work that may not be justified for the value it is bringing) then interfaces are just adding overhead now for a future feature that you may never need to support and will have to do some rewriting even if you do. YAGNI.