we could argue about "Solr leadership" :) The true leader in this market is Apache Lucene, and both Solr and Hibernate Search use Apache Lucene to manage the index.
Solr is mostly a server to provide easy access to Lucene's features, it basically exposes it via HTTP requests. Hibernate Search is not a server but embeds in your application and is specialized for Hibernate users: obviously we try do to a very good job for Hibernate/JPA users, but are not suited if not using a relational database.
100 million records is a large dataset and will require some tuning and a bit of understanding of how Lucene works, but in both cases you'll have the same problems and benefits as it really is the same library they are using. I guess you will need sharding and a multi-master configuration (but not necessarily.. depending on actual index size and workload type).
We do have big customers using these sizes or larger, unfortunately all of the big customers can't be named; still Red Hat stands behind this product so in case of need you know there is professional help and support available.. I hope you can consider that as a good hint that there are big customers sponsoring this.
While Solr can be easy to setup, using any advanced feature of Lucene is "shielded" by what the HTTP server provides. As opposing to that, we believe in making it simple enough to get started with it but we always provide access to the lower level capabilities of Lucene "native" for the case you need some very advanced feature, and this will never be possible via HTTP which will obviously never be as fast as direct access by reference.
have a look into:http://docs.jboss.org/hibernate/search/ ... ene-native
Even while facilitating most operations and managing resources properly, we allow many extensions points and direct "raw" acces so that we don't stand in the way.