Seq Documentation and Support

Welcome to the Seq documentation hub. You'll find comprehensive guides and documentation to help you start working with Seq as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    

Using SQL Server as a Metastore

Seq stores two kinds of data. Log events are stored in Seq's own storage engine, called Flare. Documents, like users and signals are stored in a separate metastore, which may be ESENT on Windows, LMDB on Linux, or a SQL database like SQL Server or PostgreSQL.

The ESENT and LMDB metastores are convenient and self-contained, but may not work reliably on some cloud filesystems. In those environments Azure Database may already be used by applications themselves, and could be a more reliable place to store Seq's documents.


Events aren't stored in the metastore

Seq won't store log events in the SQL Server database. Only documents like users and signals will be stored there. Since the metastore is usually small, even for large instances, you probably won't need to provision a large server for its documents.


Multiple Seq instances using the same SQL Server metastore are not supported

Seq assumes it has exclusive access to the metastore. Multiple Seq instances sharing the same metastore and changes made to the database directly aren't supported.

Pointing Seq at a SQL Server database

If the metastore.msSql.connectionString configuration setting is given a non-null value then Seq will use that connection string as the source of the metastore.

seq secret set -k metastore.mSSql.connectionString -v "Initial Catalog=seq-local;Integrated Security=True"

The connection string can also be specified in the SEQ_METASTORE_MSSQL_CONNECTIONSTRING environment variable.

The first time it runs, Seq will execute its migrations on the chosen schema.

Migrating an existing instance to the SQL Server metastore

As an example, say we want to use the connection string Initial Catalog=seq-local\;Integrated Security=True. An existing Seq instance can be migrated to this SQL Server database using the metastore to-mssql command:

seq metastore to-mssql --connection-string "Initial Catalog=seq-local;Integrated Security=True" --skip-config

In this example, we also pass --skip-config, so that the connection string itself isn't saved into the Seq.json file. To see a full list of options that to-mssql accepts, run seq help metastore to-mssql.

Now when starting the container, passing the same connection string in the SEQ_METASTORE_MSSQL_CONNECTIONSTRING environment variable will use that database as the metastore:

SEQ_METASTORE_MSSQL_CONNECTIONSTRING="Initial Catalog=seq-local;Integrated Security=True" seq run

Managed Service Identities for Azure SQL Database

Many Azure services use managed service identities for connecting to SQL databases. When connecting to an Azure SQL Database instance, in addition to the connection string, a managed service resource must be specified.

At the command-line, this is provided using the --msi-resource flag, and the value will normally be

When setting the resource through an environment variable, the SEQ_METASTORE_MSSQL_MSIRESOURCE variable contains this information.

If the managed service identity has access to multiple tenants, an additional --msi-tenant-id/SEQ_METASTORE_MSSQL_MSITENANTID value must be provided to select the tenant in which the identity is acting.

Updated 2 months ago

Using SQL Server as a Metastore

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.