See, even hierarchical clustering needs parameters if you want to get a partitioning out. In fact, hierarchical clustering has (roughly) four parameters: 1. the actual algorithm (divisive vs. agglomerative), 2. the distance function, 3. the linkage criterion (single-link, ward, etc.) and 4. the distance threshold at which you cut the tree (or any other extraction method).
Fact is that there doesn't exist any good "push button" solution to cluster analysis. It is an explorative technique, meaning that you have to try different methods and parameters and analyze the result.
I found DBSCAN to be very usable in most cases. Yes, it has two parameters (distance threshold aka: neighbor predicate, and minpts aka core predicate) - I'm not counting the distance function separately this time, because it's really a "is neighbor of" binary predicate that is needed; see GDBSCAN.
The reason is that in many applications you can choose these values intuitively if you have understood your data well enough. E.g. when working with Geo data, distance is literatlly in kilometers, and it allows me to intuitively specify the spatial resolution.
Similarly, minpts gives me an intuitive control over how "significant" a subset of observations needs to be before it becomes a cluster.
Usually, when you find DBSCAN hard to use, it is because you have not understood "distance" on your data yet. You then first need to figure out how to measure distance and what the resulting numbers mean to you. Then you'll know the threshold to use.
And in the end go and try out stuff. It's data exploration, not "return(truth);". There is not "true" clustering. There are only "obvious", "useless" and "interesting" clusterings, and these qualities cannot be measured mathematically; they are subjective to the user.
Inertia is only a sensible measure for spherical clusters. I.e. not for DBSCAN.
Similar reasonings apply for most internal measures: most are designed around centroid-based cluster models, not arbitrarily shaped clusters.
For DBSCAN, a sensible measure would be density-connectedness. But that needs the same parameters as DBSCAN already uses.
A recommended approach for DBSCAN is to first fix minPts according to domain knowledge, then plot a $k$-distance graph (with $k=minPts$) and look for an elbow in this graph. Alternatively, when having a domain knowledge to choose epsilon (e.g. 1 meter, when you have a geo-spatial data and know this is a reasonable radius), you can do a density plot for this radius and look for an elbow there.
Or you just use OPTICS, where epsilon only serves as an upper limit to boost performance.
Best Answer
Actually almost no internal metric can handle DBSCAN results properly.
The problem is that noise is not a cluster and almost all metrics assume the data is strictly partitioned into disjoint clusters.
Most implementations will then evaluate noise like a cluster, and the result will appear much worse than it is.
Pretty much the only metric I know (but haven't used) for this is DBCV, it supposedly is designed for density based cluster evaluation.
In general the only way to choose an evaluation metric is to understand what it does. Pick there meric whose formal approach is most closely related to your desire of a "good" cluster. Because everybody seems to have a slightly different understanding of when a cluster is "good".