<commit_before>---
date: 2018-08-06T09:00:00+00:00
title: Configure MySQL
menu:
  main:
    identifier: "configure-database-v100"
    parent: "Configuration"
    weight: 30
aliases:
    - /documentation/configure/configure-database
    - /documentation/installation/configure-database
---

Vamp uses a relational database to persist the definitions and current states of the services, gateways and workflows. This database is also used to store the user role definitions and users.

Vamp recommends using MySQL as the relational database. Though it’s possible to use PostgreSQL or Microsoft SQL server, we don’t recommend it, and if you get stuck we’re going to suggest that you to use MySQL.

Vamp has been tested with:

* Cloud SQL for MySQL service on Google Cloud Platform
* The Amazon Relational Database Service MySQL engine
* Azure Database for MySQL service
* Standalone MySQL instances

## Database Models
Vamp supports two models: *database-schema-per-namespace* and *table-per-namespace*.

### Schema per Namespace
The *database-schema-per-namespace* model offers the greatest flexibility but also has the highest overhead.

In this model, each namespace is mapped to a separate database schema. A minimum of two schemas are required for each tenant, one for the organization namespace and one for each environment.

**Benefits**

* Namespaces are loosely coupled: changes to the schema for one namespace does affect any other namespace
* Security:
  * A different user id can be assigned to each namespace
  * Each namespace can use a different database server instance for added security

**Drawbacks**

* Higher overheads: there are more schemas, users and potentially more database server instances to manage
* Lower performance : maintaining separate database connection pools for each schema has a small performance impact when scaling Vamp

### Table per Namespace
The *table-per-namespace* model offers the best performance and the lowest overhead.

In this model, each tenant is a separate database schema and each namespace is a table within that schema.

**Benefits**

* Clear ownership: one database schema for each tenant
* Security:
  * A different user id can be assigned to each tenant
  * Each tenant can use a different database server instance for added security
* Best performance: only one database connection is required for each tenant
* Lowest overheads: there are fewer schemas, users and database server instances to manage

**Drawbacks**

* Namespaces are more tightly coupled

**Benefits**

* Namespaces are loosely coupled: changes to the schema for one namespace does affect any other namespace.
* Improved security:
  * A different user id can be assigned to each namespace
  * Each namespace can use a different database server instance for added security

**Drawbacks**

* Higher overheads: there are more schemas, users and potentially more database server instances to manage.

## Security
Vamp supports a number of data at rest encryption strategies.

## Configuration

Lifter...

### Table per Namespace
The default configuration is table-per-namespace.

If you will be using use the same database server for all tenants, then you should configure this by editing the admin template and operation template. The database server host and port, username and password must be the same in both templates. You can override the username and password settings when you create the tenant (organization) and tenant environments.

If you will be using different database servers for each tenant, then you must configure each tenant (organization) and tenant environment separately.
<commit_msg>docs: content tweaks<commit_after>---
date: 2018-08-06T09:00:00+00:00
title: Configure MySQL
menu:
  main:
    identifier: "configure-database-v100"
    parent: "Configuration"
    weight: 30
aliases:
    - /documentation/configure/configure-database
    - /documentation/installation/configure-database
---

Vamp uses a relational database to persist the definitions and current states of the services, gateways and workflows. This database is also used to store the user role definitions and users.

Vamp recommends using MySQL as the relational database. Though it’s possible to use PostgreSQL or Microsoft SQL server, we don’t recommend it, and if you get stuck we’re going to suggest that you to use MySQL.

Vamp has been tested with:

* Cloud SQL for MySQL service on Google Cloud Platform
* The Amazon Relational Database Service MySQL engine
* Azure Database for MySQL service
* Standalone MySQL instances

## Database Models

Vamp's multi tenancy always uses separate schemas for each tenant. However, each tenant can also have multiple namespace.
We offer two options to handle these namespace at the database level:

- **Just one schema**. Each namespace is a table in the schema, we call this *table-per-namespace*
- **Multiple schemas**. One schema for each namespace: *database-schema-per-namespace*


### Table per Namespace
The *table-per-namespace* model offers the best performance and the lowest overhead.

In this model, each tenant is a separate database schema and each namespace is a table within that schema.

**Benefits**

* Clear ownership: one database schema for each tenant
* Security:
  * A different user id can be assigned to each tenant
  * Each tenant can use a different database server instance for added security
* Best performance: only one database connection is required for each tenant
* Lowest overheads: there are fewer schemas, users and database server instances to manage

**Drawbacks**

* Namespaces are more tightly coupled

### Schema per Namespace
The *database-schema-per-namespace* model offers the greatest flexibility but also has the highest overhead.

In this model, each namespace is mapped to a separate database schema. A minimum of two schemas are required for each tenant, one for the organization namespace and one for each environment.

**Benefits**

* Namespaces are loosely coupled: changes to the schema for one namespace does affect any other namespace
* Security:
  * A different user id can be assigned to each namespace
  * Each namespace can use a different database server instance for added security

**Drawbacks**

* Higher overheads: there are more schemas, users and potentially more database server instances to manage
* Lower performance : maintaining separate database connection pools for each schema has a small performance impact when scaling Vamp

## Security
Vamp supports a number of data at rest encryption strategies.

## Configuration

TODO Lifter...

### Table per Namespace
The default configuration is table-per-namespace.

If you will be using use the same database server for all tenants, then you should configure this by editing the admin template and operation template. The database server host and port, username and password must be the same in both templates. You can override the username and password settings when you create the tenant (organization) and tenant environments.

If you will be using different database servers for each tenant, then you must configure each tenant (organization) and tenant environment separately.

{'fraction_non_alphanumeric': 0.0481709019826864, 'fraction_numerical': 0.006422786931024853, 'mean_word_length': 4.613636363636363, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1216177', 'n_tokens_mistral': 1695, 'n_tokens_neox': 1612, 'n_words': 988}