+1 ... and there are also those users out there who just need an easy to install/use search engine for some thousand documents. A search engine with stability in mind (API and runtime). Those users are working for small to mid sized company who doesn't have dozens of developers. For them Solr is the perfect match.
I have used Solr for over 10 years now and my Solr experience has been great. Thanks for all the effort. Mihael Schmidt Software Engineering Bauformat Küchen GmbH & Co. KG Kattwinkel 1 | 32584 Löhne | Deutschland Fon: +495732 102-379 Fax: +495732 102-300 Mail: mschm...@bauformat.de<mailto:mschm...@bauformat.de> Internet: www.bauformat.de<http://www.bauformat.de> [cid:Logo_BAUFORMAT_sw_130px_61b65919-4a79-4edc-a81a-8b84d76dc540.png] Umsatzsteuer-Identifikationsnummer: DE 124323068 - Steuer-Nr.: 310/5705/0461 / Finanzamt Bünde - Handelsregister Bad Oeynhausen HRA 1801 Komplementärin: Bauformat Küchen Verwaltungs GmbH - Handelsregister Bad Oeynhausen HRB 1465 Geschäftsführer: Michael Assner, Sabine Brockschnieder <https://www.bauformat.de>[cid:e-mailbanner_hausmesse2025_e4a6f417-48a3-4e15-ac78-362c2c6359f4.jpg]<https://hausmesse.bauformat.de/2025/de/> Wir erfüllen unsere Informationspflichten zum Datenschutz gem. Artt. 13-14 DS-GVO durch Veröffentlichung auf unserer Internetseite unter: www.bauformat.de/datenschutz<http://www.bauformat.de/datenschutz> oder durch Zusendung auf Ihre formlose Anfrage. ________________________________ Von: Jan Høydahl <jan....@cominvent.com> Gesendet: Dienstag, 9. September 2025 09:53 An: users@solr.apache.org <users@solr.apache.org> Betreff: Re: Solr 10 should be a big bang release My wish is to get Solr 10.0 out the door as quickly as possible, it has tons of important, over due improvements. If I could pick one thing for v11 (which could come soon after Lucene 11), it would be a smooth implementation of SIP-14, i.e. making ZK an implementation detail. Let's remember, Solr is not run by a huge corporation with a wealthy marketing department and roadmaps. We provide software for the public good, driven by the users. So let's not talk big about bang but constant improvement in every single minor release. Major releases are most useful as a vehicele for delivering breaking changes. Want to shape the future, then BE the change by investing time in crafting good SIP's and driving them to completion. Jan > 7. sep. 2025 kl. 03:20 skrev Gus Heck <gus.h...@gmail.com>: > > Hmm, the threading on this is probably unclear. The last message was in > response to > > "Making zookeeper optional would go a long way for user goodwill and > adoption." > > On Sat, Sep 6, 2025 at 9:19 PM Gus Heck <gus.h...@gmail.com> wrote: > >> This is one of those things I find perpetually amusing and I blame it >> mostly on insufficient documentation *in solr docs* for securing and >> configuring ZK. Every large Elastic/ES cluster has an odd number of >> dedicated master nodes ... which is analogous to having a zookeeper cluster >> (the classic example in ES/OS is 3 master, 5 data, where for us it is 3 zk >> and 5 solr)... except for ES/OS it has the same product name so everyone >> sees it as simpler. The only real way they are right is that the nodes can >> share an authz/authn scheme, and one can more easily waste resources by >> giving the master nodes equal sized hardware (if one isn't paying >> attention). >> >> What we probably need here is to complete the embedded ZK SIP >> <https://cwiki.apache.org/confluence/display/SOLR/SIP-14+Embedded+Zookeeper> >> and then we too can have solr nodes with "master" roles (that just run >> embedded ZK and nothing else)... but it won't *sound* like a "2nd >> technology" that needs to be managed separately. >> >> Until then we should write docs that explicitly compare this to ES/OS. >> >> -Gus >> >> On Fri, Sep 5, 2025 at 3:40 PM matthew sporleder <msporle...@gmail.com> >> wrote: >> >>> On Fri, Sep 5, 2025 at 11:07 AM Ishan Chattopadhyaya >>> <ichattopadhy...@gmail.com> wrote: >>>> >>>> Thank you for your feedback, Andrew. I appreciate your candour and >>> passion. >>>> >>>> On Fri, 5 Sept 2025 at 12:40, Andrew Hankinson >>>> <andrew.hankinson@rism.digital> wrote: >>>> >>>>> I would guess that most, if not all, members of this list have done an >>>>> evaluation where they put Solr up against ES/OS, and chose Solr for >>> one >>>>> reason or another. >>>>> This is not a zero-sum game. >>>> >>>> >>>> For fresh adoption, unfortunately it is. As you said, those who have >>>> already chosen Solr know why they chose: my intention is not to do >>> anything >>>> different for them. >>>> >>>> >>>>> If you feel so strongly that Solr is currently a "cesspool of >>> mediocrity," >>>>> then maybe you need to find something that better fits your own needs >>> and >>>>> standards of quality. There are some (many?) of us who value the >>> stability, >>>>> and consistent incremental improvements without requiring massive >>> amounts >>>>> of rewrites at every release because somebody thinks they need to >>> follow >>>>> the latest fad. >>>>> >>>> >>>> I've upgraded Solr to Lucene 10 (SOLR-17631), it should take care of >>> those >>>> who value stability and incremental improvements, esp. performance. >>>> >>>> >>>>> >>>>> Your list seems to be written from the perspective of someone who >>> does not >>>>> actually need to take responsibility for the features that you seem to >>>>> think we need. When I see lists like this I, and probably most >>> professional >>>>> programmers, see a mountain of bugs and support questions all coming >>> at >>>>> once, on top of the work to plan, write, and test the code. >>> Incremental >>>>> improvements are a way to make these manageable. That, and most of >>> your >>>>> stuff means Solr needs to replicate functionality that is already >>>>> available. If I need a Kibana / Dashboards setup, I will use that -- >>> I'm >>>>> not going to be religious about not using it just because the >>> underlying >>>>> search engine. These are tools, not religions. >>>>> >>>> >>>> Unfortunately, there's nothing close to as good as Kibana or OpenSearch >>>> Dashboards for Solr to my knowledge. There used to be a fork of Kibana >>> for >>>> Solr (called Banana, by Andrew T of Lucidworks), but that project has >>>> likely gone stale. >>>> >>>> >>>>> There are also opportunities in your list of requests for you to >>>>> contribute back. The easiest way to get some of your requests into >>> Solr is >>>>> to take it responsibility for it, plan, write, test, and go through >>> the >>>>> review process, and commit to helping maintain it. Perhaps if you >>> were to >>>>> choose one of your items and do that, you would get a feeling for how >>> much >>>>> work you're actually talking about here, rather than (what seems like) >>>>> firing off a set of your demands for people to contribute their own >>> time >>>>> and money so that you can live in your "happy bubble". >>>>> >>>>> -Andrew >>>>> >>>>>> On 5 Sep 2025, at 02:47, Ishan Chattopadhyaya < >>> ichattopadhy...@gmail.com> >>>>> wrote: >>>>>> >>>>>>> Your list has cool stuff but I think mostly can ship at whatever >>> minor >>>>>> version. Solr has seen incremental progress over the years at minor >>>>>> releases. >>>>>> >>>>>> If we don't ship headline grabbing features in a major release, we >>> might >>>>> as >>>>>> well abandon this project and dedicate our focus on building >>> OpenSearch >>>>> or >>>>>> Elasticsearch. >>>>>> We have had so many important features in Apache Solr introduced in >>> some >>>>>> incremental release in 9.x. But, what is the perception among users >>> about >>>>>> Solr's capabilities? I will not say here what I believe people >>> think of >>>>>> Apache Solr in 2025, lest you or others shoot down the messenger of >>> bad >>>>>> news, just to stay in a happy bubble. >>>>>> >>>>>>> FWIW I think Solr 11 is very likely to occur within a year >>> following >>>>> Solr >>>>>>> 10. Maybe that's the release of your dreams, but progress will be >>>>>>> incremental (delivering value sooner). >>>>>> >>>>>> It would be very unfortunate to let Apache Solr languish in a >>> cesspool of >>>>>> mediocrity for an entire release cycle. >>>>>> >>>>>> >>>>>> On Fri, 5 Sept 2025 at 02:38, David Smiley <dsmi...@apache.org> >>> wrote: >>>>>> >>>>>>> I suppose we all have our wish list of what we want the next major >>>>> version >>>>>>> to have. I have mine (mostly geeky internal details BTW).... and >>> as the >>>>>>> need to release draws near, I get more realistic as to what >>> limited time >>>>>>> resources I'm going to spend on what topic. What can wait vs what >>>>> "needs" >>>>>>> to happen at a major version boundary. For many existing Solr >>> users, >>>>> their >>>>>>> *pressing* needs will be met with up to date versions Java & Jetty >>> & >>>>> Lucene >>>>>>> -- all things present in Solr 10 right now. Your list has cool >>> stuff >>>>> but I >>>>>>> think mostly can ship at whatever minor version. Some highly >>> wanted >>>>> things >>>>>>> will come to 9.x. Solr has seen incremental progress over the >>> years at >>>>>>> minor releases. The major releases are not that significant >>> except for >>>>> an >>>>>>> opportunity to break compatibility in some way. That is really >>>>> important >>>>>>> for us stewarding a project that's been around for almost 20 years >>> -- we >>>>>>> have to get rid of things or change things. >>>>>>> >>>>>>> FWIW I think Solr 11 is very likely to occur within a year >>> following >>>>> Solr >>>>>>> 10. Maybe that's the release of your dreams, but progress will be >>>>>>> incremental (delivering value sooner). >>>>>>> >>>>>>> On Thu, Sep 4, 2025 at 2:42 PM Ishan Chattopadhyaya < >>>>>>> ichattopadhy...@gmail.com> wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Here's my wishlist for Solr 10, to make Solr claw back the >>> lost/losing >>>>>>>> mindshare amongst developers and AI practitioners. >>>>>>>> >>>>>>>> Here's what I think Solr 10 release should have (in addition to >>>>> whatever >>>>>>> we >>>>>>>> already have): >>>>>>>> >>>>>>>> ** Vector Search / AI* >>>>>>>> - GPU based HNSW indexing >>>>>>>> - Local embeddings generation >>>>>>>> - Multi-vector fields >>>>>>>> - Visualization, metrics, recipes >>>>>>>> - Easy integration with storage and inference platforms like >>> Sagemaker, >>>>>>>> Nemo, AWS S3 Vectors and everything else >>>>>>>> - Stretch goal: Global vectors indexing support (like IVF family >>> of >>>>>>>> algorithms) >>>>>>>> - First party MCP support >>>>>>>> >>>>>>>> ** General* >>>>>>>> - Official client libraries in Python, Rust, Go, etc. >>>>>>>> - Something akin to Kibana / OpenSearch dashboards >>>>>>>> - A new modern UI with feature completeness >>>>>>>> - Entries in every meaningful AI leaderboard out there, >>> preferably at >>>>> par >>>>>>>> with other Lucene based search engines >>>>>>>> - Tons of more examples and live demos >>>>>>>> >>>>>>>> >>>>>>>> ** User experience *- Fix naming everywhere (if you know Solr, >>> you know >>>>>>>> what I mean) >>>>>>>> - No confusion around various modes of Solr >>>>>>>> - Clear documentation of the API >>>>>>>> >>>>>>>> We may be able to achieve these, or we might not be able to. If >>> we work >>>>>>>> towards these goals (or some of these), these should be >>> achievable. We >>>>>>> will >>>>>>>> be in an excellent position with regard to earning back respect >>> among >>>>> the >>>>>>>> community and placing it at par or above search and AI engines. >>> Solr 10 >>>>>>> is >>>>>>>> a great time to hit these goals. >>>>>>>> >>>>>>>> If someone has ideas (no matter how crazy, hard, or exploratory) >>> on >>>>> what >>>>>>>> else could be good to have, please help us with suggestions. >>>>>>>> >>> >>> >>> Making zookeeper optional would go a long way for user goodwill and >>> adoption. >>> >> >> >> -- >> http://www.needhamsoftware.com (work) >> https://a.co/d/b2sZLD9 (my fantasy fiction book) >> > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book)
