At present, we have our State Store information stored in the Broker Database alongside published content. We're looking to switch that up so that our state store data is stored in its own separate database.

I know this is fully supported obviously, but my question is around anything that must be done to make the switch seeing that we've been publishing content storing the state information in the broker.

Is it enough to simply temporarily disable publishing, update our deployer micro-services (deployer-conf.xml) and restart everything? I realize we'd want to clean up the broker database state data, but I'm trying to confirm whether or not there's anything else that would need migrated.

I'm assuming that what I've described would work seeing that it is just stateful data, but just looking to get confirmation. Thanks in advance!

1 Answer 1


As far as I know, the state store DB contains the state of a publish transaction during that transaction, and this data is/can be removed once that transaction has successfully finished.

This means that indeed, you can disable publishing, make sure all publish transactions are finished, set up a new state store db and reconfigure your microservices to point to the new DB.

There is no need to migrate any of the data within your current broker database to this new state store database.

  • 3
    That should be all that's required. If you can, I would recommend to (1) clear the publish queue (CME) (2) clear the /temp and /transactions folders (assuming you have no scheduled items) (3) clear the message queue Jan 27, 2020 at 21:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.