PRS is documented in the ref guide: https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#create-parameters
I know this because I started using it recently (for a new solrcloud cluster that I'm working on that will have hundreds of collections), having discovered it through https://searchscale.com/blog/prs/. I didn't realize that it was experimental and might be removed. Best, Calvin On Wed, Oct 15, 2025 at 3:23 PM David Smiley <[email protected]> wrote: > SolrCloud's "PRS" (Per Replica State) mode offers a variation on how > replica state is tracked, affecting how state is stored in ZooKeeper and > certainly affecting SolrCloud code. It solves a many-replica scalability > problem of large collections. Coincidentally, that is exactly the achilles > heel of disabling the Overseer, however PRS didn't go far enough in its > approach (IMO) as there is still replica information in state.json. I love > the conceptual idea / direction of PRS but not the implementation, which is > complex -- complexified further by being bolted onto the existing code > instead of green-field. If we are to imagine making any serious > improvements like this to how a collection's state is structured in > ZooKeeper, I can't imagine realistically doing such work with PRS > existing. I think such work would start with removing PRS without > concern/burden of compatibility. > > Thankfully, PRS is rather invisible to our users -- it's not documented in > the ref guide. I think only Full Story is using it. So it's de > facto "experimental" right now and is subject to change... **and removal**. > > FWIW I'd love to help design its replacement, but that's not the subject of > this post/thread. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley >
