Many interfaces and lots of inheritance vs few interfaces and less inheritance?
Zealous nitpicking...

am I being too zealous in trying to reduce the base class and interface inheritances

Careful with wording here: a type inherits from a base class, and implements an interface. Interfaces aren't inherited, they're implemented. Subtle, but important distinction.

My two cents...
Looking at the base class in the first snippet:

public class DbService&lt;TEntity&gt; :
    Service&lt;TRepository&gt;,
    IDbQueryableService&lt;TEntity&gt;,
    IQueryableService&lt;TEntity&gt; {}


Can you spot the code smell?
What's the difference between these two interfaces?

    IDbQueryableService&lt;TEntity&gt;
    IQueryableService&lt;TEntity&gt;


You're not listing any of these interfaces, but just from the names one can tell that IQueryableService&lt;TEntity&gt; and IDbQueryableService&lt;TEntity&gt; probably overlap in functionality: they're both queryable services.
Leaky abstractions
What you have here is a leaky abstraction: you're making an abstraction (/interface), but the implementation is leaking into the abstraction - whether the data is coming from a database, from a web service, or from text files, shouldn't matter; you want an abstraction for something that can be queried... and IQueryableService&lt;TEntity&gt; seems to accomplish that. IDbQueryableService&lt;TEntity&gt; is leaking a database implementation of an IQueryableService&lt;TEntity&gt;.
IDbQueryableService&lt;TEntity&gt; is redundant and should be removed.
Same goes for IDbGettableService&lt;TEntity&gt;, which is leaking a database implementation of IGettableService&lt;TEntity, TKey&gt;, at least so it seems from the interfaces' names.
Consistency in design
Where's IDbRemovableService&lt;TEntity&gt;? Where's IDbAddableService&lt;TEntity&gt;? Where's IDbUpdatableService&lt;TEntity&gt;? Why aren't these operations paired with a non-IDbSomething interface like the queryable and gettable stuff?

I would have lots of other questions about why you need to have a TEntityListItem (among other things), but there's really not enough context in your question to pursue any further without assuming what your implementations do, and what methods your interfaces expose.
I suggest you post another question with your actual code, so reviewers can actually go over your code and make sound recommendations. Just reviewing class names and interfaces without even having the interface members, is pretty hard.
I would venture to say that I highly doubt you need that many generic type parameters, but without knowing more about your code all I can do is say &quot;I don't like this&quot;; whether it's a private API or publicly exposed to client code doesn't matter: it's code that you need to maintain and understand, now and in the future - I don't care what Visual Studio thinks the &quot;maintainability index&quot; is (especially when anything between 20 and 100 is &quot;green&quot;). Having 12 different interfaces that, together, seem to be doing what a single repository could do, doesn't feel right. In fact, the first impression I got was &quot;boy this is over-engineered&quot;. And I'm sure the impression wouldn't go away by looking at your actual code.