> For the complete documentation index, see [llms.txt](https://brightercommand.gitbook.io/paramore-brighter-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://brightercommand.gitbook.io/paramore-brighter-documentation/brighter-configuration/brighterbasicconfiguration/relationaldatabaseconfigurationreference.md).

# Relational Database Configuration Reference

RelationalDatabaseConfiguration is the one type that configures every relational Outbox, Inbox, provisioner and queue-table transport Brighter ships.

> **Reference** · Applies to **Brighter V10** · Prerequisites: [Basic Configuration](/paramore-brighter-documentation/brighter-configuration/brighterbasicconfiguration.md)

`RelationalDatabaseConfiguration` is the one type that configures every relational Outbox, Inbox, provisioner and queue-table transport Brighter ships. Seventeen components take it, and none of them adds an option of its own.

That is why this page exists. A table repeated on seventeen pages is seventeen chances for one of them to be wrong, and the wrong one is indistinguishable from the right ones to a reader who only opens the page for the store they are using.

## Relational Database Configuration Options

The options are constructor parameters, so **the option is the parameter you type**; the property you read back is the same word capitalised.

| Option                    | Type        | Default      | Description                                                                                                            |
| ------------------------- | ----------- | ------------ | ---------------------------------------------------------------------------------------------------------------------- |
| `connectionString`        | `string`    | `none`       | Connects to the database, in the provider's own format.                                                                |
| `databaseName`            | `string?`   | `"Brighter"` | Names the database holding the tables.                                                                                 |
| `outBoxTableName`         | `string?`   | `"Outbox"`   | Names the Outbox table.                                                                                                |
| `inboxTableName`          | `string?`   | `"Inbox"`    | Names the Inbox table; the property is `InBoxTableName`.                                                               |
| `queueStoreTable`         | `string?`   | `"Queue"`    | Names the queue table the MSSQL and PostgreSQL transports read.                                                        |
| `schemaName`              | `string?`   | `null`       | Qualifies the tables with a schema; the provider's own default applies when null.                                      |
| `binaryMessagePayload`    | `bool`      | `false`      | Stores the message body as bytes rather than as UTF-8 text.                                                            |
| `jsonMessagePayload`      | `bool`      | `false`      | Stores the message body in the database's native JSON type.                                                            |
| `outstandingCountTimeout` | `TimeSpan?` | `null`       | The command timeout for the Outbox's count of outstanding messages; `null` is 15 seconds. Rounded up to whole seconds. |

Only `connectionString` is required. The three table names default to `Outbox`, `Inbox` and `Queue`, so a component that uses one of them needs no configuration beyond the connection.

`binaryMessagePayload` and `jsonMessagePayload` change the column the payload is written to, so **changing either against an existing table is a migration, not a setting**. See [Database Provisioning](/paramore-brighter-documentation/outbox-and-inbox/boxprovisioning.md).

`outstandingCountTimeout` bounds the count an Outbox runs when `MaxOutStandingMessages` is set, from Brighter 10.8.1; before it, the count had no timeout, and a lock on the Outbox table could hold it, and the limit check waiting on it, indefinitely. A count that times out is logged and read as 0, so while it keeps timing out the limit does not stop posts. The value replaces any command timeout in the connection string for that query, and must be greater than zero and at most 2,147,483 seconds, or the constructor throws `ArgumentOutOfRangeException`. On Spanner the default falls from 60 seconds to 15. The Sweeper's read of outstanding messages keeps its own timeout.

## Which Components Take the Relational Configuration

Seventeen, across four families, measured at `10.8.0` by looking for `IAmARelationalDatabaseConfiguration` in each package.

| Family           | Provider                                  | Page                                                                                                                              |
| ---------------- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Outbox           | MSSQL                                     | [MSSQL Outbox](/paramore-brighter-documentation/outbox-and-inbox/brighteroutboxsupport/mssqloutbox.md)                            |
| Outbox           | MySQL                                     | [MySQL Outbox](/paramore-brighter-documentation/outbox-and-inbox/brighteroutboxsupport/mysqloutbox.md)                            |
| Outbox           | PostgreSQL                                | [PostgreSQL Outbox](/paramore-brighter-documentation/outbox-and-inbox/brighteroutboxsupport/postgresoutbox.md)                    |
| Outbox           | SQLite                                    | [SQLite Outbox](/paramore-brighter-documentation/outbox-and-inbox/brighteroutboxsupport/sqliteoutbox.md)                          |
| Outbox           | Spanner                                   | [Spanner Outbox](/paramore-brighter-documentation/outbox-and-inbox/brighteroutboxsupport/spanneroutbox.md)                        |
| Inbox            | MSSQL                                     | [MSSQL Inbox](/paramore-brighter-documentation/outbox-and-inbox/brighterinboxsupport/mssqlinbox.md)                               |
| Inbox            | MySQL                                     | [MySQL Inbox](/paramore-brighter-documentation/outbox-and-inbox/brighterinboxsupport/mysqlinbox.md)                               |
| Inbox            | PostgreSQL                                | [PostgreSQL Inbox](/paramore-brighter-documentation/outbox-and-inbox/brighterinboxsupport/postgresinbox.md)                       |
| Inbox            | SQLite                                    | [SQLite Inbox](/paramore-brighter-documentation/outbox-and-inbox/brighterinboxsupport/sqliteinbox.md)                             |
| Inbox            | Spanner                                   | [Spanner Inbox](/paramore-brighter-documentation/outbox-and-inbox/brighterinboxsupport/spannerinbox.md)                           |
| Box provisioning | MSSQL, MySQL, PostgreSQL, SQLite, Spanner | [Configuring Box Provisioning](/paramore-brighter-documentation/outbox-and-inbox/boxprovisioning/boxprovisioningconfiguration.md) |
| Transport        | PostgreSQL                                | [PostgreSQL Message Broker](/paramore-brighter-documentation/transports/postgresqlmessagebroker.md)                               |
| Transport        | MSSQL                                     | [MSSQL Message Broker](/paramore-brighter-documentation/transports/mssqlmessagebroker.md)                                         |

**The two transports are the entries to know about.** A queue-table transport is not an Outbox, and it is easy to assume the relational configuration reaches only the box packages — it does not. `queueStoreTable` exists for those two and for nothing else.

## Registering the Relational Configuration

The components that take this type do not resolve it from the container by themselves: Brighter's provisioning and sweeper hosted services do. So it is registered **once**, as a singleton against the interface, and passed **explicitly** to each component that needs it.

```csharp
using Microsoft.Extensions.DependencyInjection;
using Paramore.Brighter;
using Paramore.Brighter.Extensions.DependencyInjection;
using Paramore.Brighter.Outbox.PostgreSql;
using Paramore.Brighter.PostgreSql;

public void ConfigureServices(IServiceCollection services)
{
    var configuration = new RelationalDatabaseConfiguration(
        connectionString: DbConnectionString(),
        outBoxTableName: "Outbox");

    // Registered once, against the interface: this is what the provisioner reads
    services.AddSingleton<IAmARelationalDatabaseConfiguration>(configuration);

    services.AddBrighter()
        .AddProducers(configure =>
        {
            // ... your producer registry
            configure.Outbox = new PostgreSqlOutbox(configuration);   // passed explicitly too
            configure.ConnectionProvider = typeof(PostgreSqlConnectionProvider);
        })
        .AutoFromAssemblies();
}
```

Passing the same object twice — once to the container and once to the component — is the shape every relational page shows, and [PostgreSQL Outbox](/paramore-brighter-documentation/outbox-and-inbox/brighteroutboxsupport/postgresoutbox.md) shows it in full.

## Further Reading

* [Basic Configuration](/paramore-brighter-documentation/brighter-configuration/brighterbasicconfiguration.md) — where the registration above fits in a whole application
* [Command Processor Configuration Reference](/paramore-brighter-documentation/brighter-configuration/brighterbasicconfiguration/commandprocessorconfigurationreference.md) — the producers configuration that takes the Outbox this type configures
* [Database Provisioning](/paramore-brighter-documentation/outbox-and-inbox/boxprovisioning.md) — who creates the tables these options name
* [Outbox Support](/paramore-brighter-documentation/outbox-and-inbox/brighteroutboxsupport.md) — why a relational Outbox is worth the table


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://brightercommand.gitbook.io/paramore-brighter-documentation/brighter-configuration/brighterbasicconfiguration/relationaldatabaseconfigurationreference.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
