By default Stambia runtime is using an internal H2 database as the log database.

This makes it extremely easy to launch the runtime out-of-the box because you do not need to install additional software on your machine.


However for specific reasons, you can choose to use another database.

Below you will find some ideas that should make it easier for you to choose the right log database for your runtime.


1. Choose a database that has an official jdbc driver 


Being a java application, Stambia Runtime connects to database via jdbc drivers. It is therefore necessary to choose a database that can be easily accessed via jdbc.

It goes without saying that the jdbc driver in question has to be installed in the runtime directory for the runtime to be able to connect to the log database.


2. Choose a robust database


Log database stocks the details of all the sessions executed by the Runtime. 

In a production environment this might be a significant amount of data that all Stambia applications will need to access (Designer/Analytics to read the data, Runtime to save the session details).

Normally any of the major recognized database technologies is a good choice (like Microsoft SQL Server, MySQL, Postgres, Oracle etc.).


3. Choose a database for which your company has a good technical know-how


If for example all your applications are using MSSQL databases and you have a dedicated team of MSSQL DBAs who make sure that your databases are up and running and in good health, choosing MSSQL is probably the best solution for you.

Just like any database, the log database requires maintenance and supervision. 

If you have a DBA team that monitors the log database's health, a serious issue impacting your production environment is less likely to occur.

And even if it happens, your experts will be able to quickly fix it and make the log database operational again, because they know how to manage this database product.


4. Monitor your database and keep it well maintained.


Any database without a proper maintanace will fail at some point.

Make sure you do not forget to maintain your log database (especially in terms of the resources available to your database).

If you want to keep the size of your database reasonable you should consider scheduling a purge which will limit the number of sessions kept in your database (for example to keep only the sessions from the last month).


5. Make sure to use the runtime parameters adapted to the chosen rdbms technology


Once you have decided which technology to use make sure to use dedicated set of parameters in your runtime's configuration file (you can find them in properties/samples folder in your runtime's installation). 

Some technologies have slightly different configuration than others. 

It's for example the case for Microsoft Sql Server where it is advised to use a specific parameter in jdbc connection to avoid deadlocks on the log database.


6. One environment, one log database

It is recommended that each environment have its own log database. You must avoid having the same log schema for all environments: this is tempting to simplify your life, but in the end, you mix up the logs and complicate the operations of purging and updating the runtimes.