I was wondering if there has been any talk/discussion around the possibility of having SQL being the persistence storage for service control rather than the embedded Ravendb?
Hi
We are aware of scalability issues caused by using an embedded RavenDB database and are looking for alternative solutions. We have not yet decided on the actual technology stack though. SQL Server is one of the options, especially for on-premise deployments. We have an issue open for this so if you would like to be notified when we actually start working on this, please subscribe.
Just out of curiosity, what is you motivation for using SQL instead of RavenDB? Is it infrastructure maintenance, reliability, throughput or some other reason?
Szymon
Thanks for the info!
The motivation for us is that we have had a lot of issues with Ravendb persistence with our endpoints and are in the process of moving to SQL persistence for all of those. We also don’t have much expertise around Ravendb and our DBA team isn’t a fan of it either.
We have also had some issues with our service control ravendb getting extraordinarily large which has lead us to increase the servers resources a bunch of times. The process of compaction for Ravendb hasn’t been very smooth in our experiences the few times we have done it.
One other small thing and i’m not sure if it related to Ravendb or not but whenever we update service control / restart the server, it sometimes takes a few days for all of the messages to show up in service insight. It almost looks like it is reprocessing/reindexing all of the messages because it starts from the oldest message to the latest. I think it has something to do with the cleanup process of old messages but this causes us some issues when we can’t see what is happening in the system at that time