I cannot, because I don’t have any.
I wouldn’t expect Hibernate Search to perform much better, if better at all, on a small (single-node) application. Oracle would have a lot of potential for optimization in that case, since it would be handling everything (DB writing/reading, full-text indexing/querying) in the same place.
The main advantage of Hibernate Search is generally the ease of use, configurability and richness of the feature set. I don’t know where Oracle FullText stands these days, but it used to be severely lacking when it comes to configuring text parsing. Elasticsearch, on the other hand, is based on Lucene and is highly configurable.
If you end up doing a benchmark yourself, it would be nice to share it here, so that others like you from the community can benefit from it Note that a benchmark is generally only useful to others if the results are accompanied with a description of the methodology, data set and hardware specs, and ideally the source code of the benchmark, so that others can judge whether it’s relevant to them and reproduce the benchmark in their own environment.
When querying, by default Hibernate Search will return a managed entity, whose data is fetched from the database, so that it is up-to-date, can be updated, and can benefit from Hibernate ORM’s lazy-loading.
If you want to fetch data from the Elasticsearch index instead, you can use field projections, optionally combining multiple fields using a composite projection. But then, obviously the result won’t be a managed entity, so you won’t be able to apply (and persist) changes to returned objects or to benefit from lazy-loading.
At some point we will provide projections from the index to custom types (records, DTO), but we haven’t started working on that yet.
Note you can also project to the source document from Elasticsearch, if that’s useful to you.