Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Solr is one of those technologies which works but isn't really glorious to use and is bit stuffy with its XML configurations and Java interfaces. It's a bit of shame, because search engines are so popular nowadays and everybody seems to be fixated on using ElasticSearch. Which from what I've read and heard is resource-hungry and not really cut for simple text-search.

Maybe someday somebody will create a new search engine that will be hipster and easy to use, like Algolia but open-source. I'm bit curious though how incumbent Lucene is as the core search engine that it would even make sense to try and recreate it in another language. Probably too much that unless somebody has money to throw around it will remain so to the far future.



Search really has 3 main levels.

1. Core ranked inverted index data store (Lucene)

2. API layer on top of Lucene with easier query, index, data importing, sharding, etc. (Solr/Elastic Search)

3. Fully hosted API / UI for easier GUI for developers and search relevance engineers (Algolia, Lucidworks Fusion).

The new hotness in search is currently Rust-based tooling. Rust is a great application for search as it's very performance-sensitive and data-structure heavy, and once the indexes are built are fairly stable, leading to the 90th+ percentile latencies and throughput to be much better than Lucene-based libraries that are built on top of the JVM.

For the low level core search engine like Lucene (inverted indexes, TF-IDF ranking, etc), there's Tantivy [1]

For the middle tier (ES) there's Sonic [2]

MeiliSearch [3] is a play for the hipster open-source Algolia. It's in Rust, is MIT licensed, supports self-hosting, has an out of the box web interface.

[1] https://github.com/tantivy-search/tantivy [2] https://github.com/valeriansaliou/sonic [3] https://github.com/meilisearch/MeiliSearch


Cool, very interesting! Thanks for the summary, I had/have a project that currently uses Solr for quick text search yet the integration has not been totally painless. Also it's kind of ridiculous how much RAM even the tiniest instance uses.

I myself picked up Solr (instead of ES) as it was recommended as better bet for my use case but I did not research in full what others options there were.

Rust seems like a smart choice like it probably is for this type of very fast processing. I guess this is yet another reason to learn it.


I also found a nice overview in the MeiliSearch documentation [1]. Maybe, you find it interesting.

[1] https://docs.meilisearch.com/resources/comparison_to_alterna...


And the need for ZooKeeper with SolrCloud. We had to have at least one person working full time to keep a decent sized cluster working correctly.


This mirrors my experience. The Solr Cluster that we have in production requires full time attention of our infrastructure team.


Never bothered with solr cloud and our simple replicated cluster that pretty much auto scales from 3 nodes to 100+ across multiple regions takes maybe a few hours of maintenance every few months, and no one dedicated to baby sit it...

In summary, avoid SolrCloud like plague.


I had an opposite experience: solr was rock solid and didn’t require too much maintenance.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: