Hide menu Last updated: May 17 2016

­Database mode

[New in Episerver Core 9.7.0]

Episerver has introduced database mode configuration. The database mode configuration has two options: ReadWrite and ReadOnly (see Configuration).

ReadWrite mode

The ReadWrite mode is the default mode and the application works as normal.

ReadOnly mode

In the ReadOnly mode, the application can only load data from database. The saving and updating operations by EPiServer.Data.IDatabaseHandler throw exceptions, which is why some modules are disabled or work differently. These modules and functions are affected in the ReadOnly mode:

  1. Scheduler Service is disabled.
  2. Model synch is disabled.
  3. Indexing of content is disabled.
  4. User, role and claims synch are disabled.
  5. Automatic database updating throws exception if updating is needed.
  6. Statistics Logger is disabled.
  7. Saving web config file into database is disabled.


The database mode can be configured by the databaseMode attribute on the episerver.dataStore section or by the episerver:DatabaseMode setting under the appSettings section.

Example of setting the ReadOnly mode by episerver.dataStore section:

<episerver.dataStore databaseMode="ReadOnly"></episerver.dataStore>

Example of setting ReadOnly mode by appsetting section:


    <add key="episerver:DatabaseMode" value="ReadOnly" />


Find Database mode by code

The IDatabaseMode can be used to find and detect the database mode by code:


Accessing Protected Module in the ReadOnly mode

By default, HttpException returns status code 503 when accessing a protected module in the ReadOnly mode. You can override this behavior by listening to the AccessPath event. 

ServiceLocator.Current.GetInstance<IAccessReadOnlyProtectedModules>().AccessPath += (object sender, ReadOnlyProtectedModuleEventArgs e) =>

{ e.Handled = true; // Put your code here redirect to a custom readonly page… }

Override the default ReadOnly page

Set the episerver:ReadOnlyInfoUrl appSetting to override the default ReadOnly page (~/Util/ReadOnly.aspx)

    <add key="episerver:ReadOnlyInfoUrl" value="~/OurCustomReadOnlyPage.html" />


It would be nice to provide some sort of GUI to enable/disable this. I can imagine lots of use cases where you want to turn on read only mode without having to do a full deploy or fiddle with files directly on the server.

Thank you for input, we can look at it.

Btw: To changing of the database mode it needs restart of application and if you are in the cloud environment (azure environment) the appsettings can be overrided from azure portal UI.

Should I use read-only mode on front-end servers and edit server in read-write mode in multi-server single-db setup? It looks like we do same things as read-only mode for front-end servers (deny access to edit mode, disable scheduler etc).

It is not necessary to do it, the feature read-only mode currently is related to if the Database is in the read-only (to avoiding get exception). When the application is in the read-only mode then the CMS database handler refuse to update the database (all save action throw exception). But you can set the front-end to read-only if you are sure there is no module that needed updating database by using EPiServer CMS database handler (such as comments, forms and ect).

Is there a reason that the site needs to recycle to set ReadOnly?

Would me replacing the IDatabaseMode that reads from something that can be set in runtime cause any problems?

unfortunately you need to recycle application there are lot of modules and component that need to be adjusted when the database mode changes. Right now the database mode reads from configuration in the initialization phase and the behavoir of component be changed according to it (different implementation in the container). By other words It is a complex problem becuase of behavior changing. The easiest way is to restart the application. 

Great! This is in an interesting feature in scenarios where you might want distributed webfronts pointing to an azure geo-replicated database. 
Few questions though: What happens with core functionatilities such as Episerver DDS, XForms and EPiServer Forms in this approach? Is there a way to "direct" those write calls to a "primary" database? 

Today there is no way to redirect them to primary database. 

"unfortunately you need to recycle application there are lot of modules and component that need to be adjusted when the database mode changes."
Is this still the case?

How do you handle this in DXC, do you also recycle the production app? (in cases with pending schema changes and you need to replicate and update the database first)