# Database Access High Availability (HA)

You can deploy the Teleport Database Service in a Highly Available (HA) configuration using two methods, both of which involve pointing multiple Database Service instances to the same database instance:

- Deploying multiple Database Service instances with the same dynamic resource watchers.
- Deploying multiple Database Service instances configured to proxy the same database instances.

## Dynamic resource watchers

You can configure multiple Database Service replicas to watch for the same dynamic `db` resources.

To configure the Database Service to watch for dynamic resources, add a `labels` field to its `resources` configuration:

```
db_service:
  enabled: true
  resources:
  - labels:
      "region": "us-east-1"

```

When you create a dynamic `db` resource, all Database Service replicas configured to watch that `db` resource's labels will proxy the corresponding database instance. For example, the `db_service` configuration above instructs the Database Service to proxy any `db` resource with the `region:us-east-1` label.

When connecting, Teleport will randomly pick the Database Service instance to connect through to provide some load balancing. If the selected instance is down (e.g. in case of a data center outage), Teleport will try to connect via other instances.

For information on setting up dynamic database resources, see [Dynamic Database Registration](https://goteleport.com/docs/ver/17.x/enroll-resources/database-access/guides/dynamic-registration.md).

## Static Database Service configuration

You can explicitly configure Database Service replicas to connect to the same database instances using the Database Service's static configuration. This approach is useful if you expect the databases you will proxy via Teleport to remain stable over time.

There are two approaches to deploying the Database Service in high availability using static configuration, which we will describe below:

- **Combined replicas**: Teleport load balances database traffic across Database Service replicas
- **Separate replicas**: Clients choose which agent to use to connect to a database

### Combined replicas

If you have two Database Services proxying the same database, configuration for both agents would be identical:

```
# Same config for both agents.
db_service:
  enabled: true
  databases:
  - name: "postgres"
    protocol: "postgres"
    uri: "postgres.example.com:5432"

```

With this configuration, you will see only a single entry for the database in `tsh db ls`:

```
$ tsh db ls
Name
--------
postgres

$ tsh db connect postgres
```

As with dynamic resources, Teleport will randomly pick a Database Service instance to connect through to when connecting to a database.

### Separate replicas

With separate replicas, each Database Service instance proxying the database assigns it a different name. This allows you to explicitly pick the agent you want to connect to the database over:

```
# Database service instance #1.
db_service:
  enabled: true
  databases:
  # Note the name is different than instance #2 but the URI is the same.
  - name: "postgres-us-east-1a"
    protocol: "postgres"
    uri: "postgres.example.com:5432"

```

```
# Database service instance #2.
db_service:
  enabled: true
  databases:
  # Note the name is different than instance #1 but the URI is the same.
  - name: "postgres-us-east-1b"
    protocol: "postgres"
    uri: "postgres.example.com:5432"

```

With this configuration, both services will appear as two separate entries in `tsh db ls` output and you will have to pick one explicitly when connecting:

```
$ tsh db ls
Name
-------------------
postgres-us-east-1a
postgres-us-east-1b

$ tsh db connect postgres-us-east-1a
```

This approach is useful when you want to have control over which replica you're using to connect.

## Next steps

- Get started by [connecting](https://goteleport.com/docs/ver/17.x/enroll-resources/database-access/guides.md) your database.
- Review the [architecture](https://goteleport.com/docs/ver/17.x/reference/architecture/agents.md) of the Teleport Database Service and other services that run on Teleport Agents.