NavigationContentFooter

Managed Database for PostgreSQL and MySQL API

Introduction

Managed Database for PostgreSQL and MySQL provides fully-managed relational Database Instances, with MySQL or PostgreSQL as database engines. The resource allows you to focus on development rather than administration or configuration. It comes with a high-availability mode, data replication, and automatic backups.

Compared to traditional database management, which requires customers to provide their infrastructure and resources to manage their databases, Managed Database for PostgreSQL and MySQL Instance offers the user access to Database Instances without setting up the hardware or configuring the software. Scaleway handles the provisioning, manages the configuration, and provides useful features as high availability, automated backup, user management, and more.

Concepts

Refer to our to find definitions of the different terms referring to Managed Database for PostgreSQL and MySQL.

Quickstart

  1. Configure your environment variables.

    Note

    This is an optional step that seeks to simplify your usage of the APIs.

    export SCW_ACCESS_KEY="<API access key>"
    export SCW_SECRET_KEY="<API secret key>"
    export SCW_REGION="<Scaleway region>"
  2. Edit the POST request payload you will use to create your Database Instance. Replace the parameters in the following example:

    '{
    "project_id": "d8e65f2b-cce9-40b7-80fc-6a2902db6826",
    "name": "myDB",
    "engine": "PostgreSQL-15",
    "tags": ["donnerstag"],
    "is_ha_cluster": true,
    "node_type": "db-pro2-xxs",
    "disable_backup": false,
    "user_name": "my_initial_user",
    "password": "thiZ_is_v0ry_s3cret",
    "volume_type": "bssd",
    "volume_size": "30000000000"
    }'
    ParameterDescription
    project_idThe ID of the Project you want to create your Database Instance in. To find your Project ID you can or consult the .
    engineREQUIRED Version ID of the database engine. To check the list of available engines you can use the folowing endpoint: https://api.scaleway.com/rdb/v1/regions/$SCW_REGION/database-engines
    nameName of the Database Instance
    node_typeREQUIRED The node type. To check the list of available node types you can use the folowing endpoint: https://api.scaleway.com/rdb/v1/regions/$SCW_REGION/node-types
    is_ha_clusterBOOLEAN Defines whether High Availability is enabled for the Database Instance
    disable_backupBOOLEAN Defines whether automated backups are disabled for the Database Instance
    tagsThe list of tags ["tag1", "tag2", ...] that will be associated with the Database Instance. Tags can be appended to the query of the call to show results for only the Database Instances using a specific tag. You can also combine tags to list Database Instances that posess all the appended tags.
    user_nameREQUIRED Identifier of the default user, which is created concurrently with the Database Instance
    passwordREQUIRED Password for the default user
    volume_typeType of volume where data is stored. You can specify either local volume (lssd) or block volume (bssd). The default value is lssd
    volume_sizeVolume size when volume_type is bssd. The value should be expressed in bytes. For example 30GB is expressed as 30000000000
  3. Create a Database Instance by running the following command. Make sure you include the payload you edited in the previous step.

    curl -X POST \
    -H "X-Auth-Token: $SCW_SECRET_KEY" \
    "Content-Type: application/json" \
    https://api.scaleway.com/rdb/v1/regions/$SCW_REGION/instances \
    -d '{
    "project_id": "d8e65f2b-cce9-40b7-80fc-6a2902db6826",
    "name": "myDB",
    "engine": "PostgreSQL-15",
    "tags": ["donnerstag"],
    "is_ha_cluster": true,
    "node_type": "db-pro2-xxs",
    "disable_backup": false,
    "user_name": "my_initial_user",
    "password": "thiZ_is_v0ry_s3cret",
    "volume_type": "bssd",
    "volume_size": "30000000000"
    }'
  4. List your Database Instances.

    curl -X GET \
    -H "Content-Type: application/json" \
    -H "X-Auth-Token: $SCW_SECRET_KEY" https://api.scaleway.com/rdb/v1/regions/$SCW_REGION/instances

    You should get a response like the following:

    Note

    This is a response example, the UUIDs and IP address displayed are not real.

    {
    "id": "f5122f66-fb50-4cef-aa02-487ef4fc1af0",
    "name": "myDB",
    "organization_id": "895693aa-3915-4896-8761-c2923b008be7",
    "project_id": "d8e65f2b-cce9-40b7-80fc-6a2902db6826",
    "status": "ready",
    "engine": "PostgreSQL-15",
    "endpoint": {
    "ip": "198.51.100.0",
    "port": 22245,
    "name": null
    },
    "tags": [
    "donnerstag"
    ],
    "settings": [],
    "backup_schedule": {
    "frequency": 24,
    "retention": 7,
    "disabled": true
    },
    "is_ha_cluster": true,
    "read_replicas": [],
    "node_type": "db-pro2-xxs",
    "volume": {
    "type": "bssd",
    "size": 30000000000
    }
    "created_at": "2019-04-19T16:24:52.591417Z",
    "region": "fr-par"
    }
  5. Retrieve your Database Instance IP and port from the response.

    Note

    In the example above, the IP and port are 198.51.100.0 and 22245, respectively.

  6. Connect to your Database Instance with the database client of the engine you selected. For MySQL, run the following command:

    mysql -h <ip-address> --port <port> -p -u <user_name>

    For PostgreSQL, run:

    psql -h <ip-address> -p <port> -U <username> -d rdb

    For the recurring example, the command would look like:

    psql -h 198.51.100.0 -p 22245 -U my_initial_user -d rdb
  7. Enter the database password that you defined upon creation.

You are now connected to your Managed Database.

Requirements

To perform the following steps, you must first ensure that:

  • you have an account and are logged into the
  • you have created an and that the API key has sufficient to perform the actions described on this page.
  • you have

Technical Information

Regions

Scaleway's infrastructure is spread across different .

Managed Database for PostgreSQL and MySQL is available in the Paris, Amsterdam and Warsaw regions, which are represented by the following path parameters:

  • fr-par
  • nl-ams
  • pl-waw

PostgreSQL specifications

Versions

Scaleway Database for PostgreSQL supports PostgreSQL versions 11, 12, 13, 14 and 15.

System

Different modules are available for installation, including TimescaleDB and PostGIS. Refer to the for an extensive list of PostgreSQL extensions.

Database Management

You can create logical databases through the Scaleway console, the Scaleway APIs or SQL.

  • databases created using the Scaleway console or the API are owned by an internal system user. These are called "managed databases".
  • databases created using SQL will be owned by the creator. These are called "unmanaged databases".

MySQL specifications

Versions

Scaleway Database for MySQL supports MySQL 8.

System

  • only the is supported
  • the is enabled.
  • (default) and authentication are supported.

User Management

  • users with an admin role have access to all logical databases and can create new ones.
  • users created via the API are authenticated using the default authentication plugin, which can be changed in the settings.

Technical Limitations

PostgreSQL

User Management

  • users with an admin role have CREATEROLE and CREATEDB privileges.
  • users do NOT have SUPERUSER nor REPLICATION privileges.
  • permission management through the Scaleway console or API is only possible for the "managed databases".

Backup and restoration

Databases that have been backed up and then restored retain the user permission settings in use at the time of backup. If you delete users after backup and then restore your backup in the same database, or if you restore a backup to a different database with different or no users, the permissions configured for them continue to exist, but with no associated owner. This error will put a stop to the restoration process.

To avoid this issue, we recommmend you re-create the users you deleted. In the occasion you restore the backup to a new database, you must create new users with the same names.

Going Further

For more information about Managed Database for PostgreSQL and MySQL, you can check out the following pages:

  • join the #database channel

How to migrate a database

If you wish to migrate existing databases to a Managed Database for PostgreSQL or MySQL, you can refer to the tutorial page.

Troubleshoooting

Disk full status

If your Database Instance uses local storage, your local volume might eventually approach full capacity and shift to disk_full mode. This mode grants you enough space to either or .

Backups

A database backup is a dated export of a Database Instance stored on an offsite backend located in a different region than your database, by default. Once a backup is created, it can be used to restore the database. Each logical database in a Database Instance is backed up and can be restored separately.

GET
/rdb/v1/regions/{region}/backups
POST
/rdb/v1/regions/{region}/backups
GET
/rdb/v1/regions/{region}/backups/{database_backup_id}
PATCH
/rdb/v1/regions/{region}/backups/{database_backup_id}
DELETE
/rdb/v1/regions/{region}/backups/{database_backup_id}
POST
/rdb/v1/regions/{region}/backups/{database_backup_id}/export
POST
/rdb/v1/regions/{region}/backups/{database_backup_id}/restore

Engines

A database engine is the software component that stores and retrieves your data from a database. Currently PostgreSQL 11, 12, 13 and 14 are available. MySQL is available in version 8.

GET
/rdb/v1/regions/{region}/database-engines

Database Instances

A Database Instance is made up of one or multiple dedicated compute nodes running a single database engine. Two node settings are available: High-Availability (HA), with a main node and one replica, and standalone with a main node. The HA standby node is linked to the main node, using synchronous replication. Synchronous replication offers the ability to confirm that all changes intended by a transaction have been transferred and applied to the synchronous replica node, providing durability to the data.

Note: HA standby nodes are not accessible to users unless the main node becomes unavailable and the standby takes over. If you wish to run queries on a read-only node, you can use

Read Replicas can be used for certain read-only workflows such as Business Intelligence, or for a read-only scaling of your application. Read Replicas use asynchronous replication to replicate data from the main node.

GET
/rdb/v1/regions/{region}/instances
POST
/rdb/v1/regions/{region}/instances
GET
/rdb/v1/regions/{region}/instances/{instance_id}
PATCH
/rdb/v1/regions/{region}/instances/{instance_id}
DELETE
/rdb/v1/regions/{region}/instances/{instance_id}
POST
/rdb/v1/regions/{region}/instances/{instance_id}/apply-maintenance
GET
/rdb/v1/regions/{region}/instances/{instance_id}/certificate
POST
/rdb/v1/regions/{region}/instances/{instance_id}/clone
GET
/rdb/v1/regions/{region}/instances/{instance_id}/logs
GET
/rdb/v1/regions/{region}/instances/{instance_id}/logs-details
GET
/rdb/v1/regions/{region}/instances/{instance_id}/metrics
POST
/rdb/v1/regions/{region}/instances/{instance_id}/prepare-logs
POST
/rdb/v1/regions/{region}/instances/{instance_id}/purge-logs
POST
/rdb/v1/regions/{region}/instances/{instance_id}/renew-certificate
POST
/rdb/v1/regions/{region}/instances/{instance_id}/restart
POST
/rdb/v1/regions/{region}/instances/{instance_id}/upgrade
GET
/rdb/v1/regions/{region}/logs/{instance_log_id}

Read Replicas

A Read Replica is a live copy of a Database Instance that behaves like an Instance, but that only allows read-only connections. The replica mirrors the data of the primary Database node and any changes made are replicated to the replica asynchronously. Read Replicas allow you to scale your Database Instance for read-heavy database workloads. They can also be used for business intelligence workloads.

A Read Replica can have at most one direct access and one Private Network endpoint. Loadbalancer endpoints are not available on Read Replicas even if this resource is displayed in the Read Replica response example.

If you want to remove a Read Replica endpoint, you can use API call.

Instance Access Control Lists (ACL) also apply to Read Replica direct access endpoints.

Limitations: There might be replication lags between the primary node and its Read Replica nodes. You can try to reduce this lag with some good practices:

  • All your tables should have a primary key
  • Don't run large transactions that modify, delete or insert lots of rows. Try to split it into several small transactions.
POST
/rdb/v1/regions/{region}/read-replicas
GET
/rdb/v1/regions/{region}/read-replicas/{read_replica_id}
DELETE
/rdb/v1/regions/{region}/read-replicas/{read_replica_id}
POST
/rdb/v1/regions/{region}/read-replicas/{read_replica_id}/endpoints
POST
/rdb/v1/regions/{region}/read-replicas/{read_replica_id}/promote
POST
/rdb/v1/regions/{region}/read-replicas/{read_replica_id}/reset

ACLs

Network Access Control Lists allow you to control incoming network traffic by setting up ACL rules.

GET
/rdb/v1/regions/{region}/instances/{instance_id}/acls
POST
/rdb/v1/regions/{region}/instances/{instance_id}/acls
PUT
/rdb/v1/regions/{region}/instances/{instance_id}/acls
DELETE
/rdb/v1/regions/{region}/instances/{instance_id}/acls

Instance Settings

Advanced Database Instance settings allow you to tune the behavior of your database engines to better fit your needs.

Available settings depend on the database engine and its version. Note that some settings can only be defined upon database engine initialization. These are called init settings. You can find a full list of the settings available in the response body of the endpoint.

Each advanced setting entry has a default value that users can override. The deletion of a setting entry will restore the setting to default value. Some of the defaults values can be different from the engine's defaults, as we optimize them to the Scaleway platform.

POST
/rdb/v1/regions/{region}/instances/{instance_id}/settings
PUT
/rdb/v1/regions/{region}/instances/{instance_id}/settings
DELETE
/rdb/v1/regions/{region}/instances/{instance_id}/settings

Privileges

Privileges are permissions that can be granted to database users. You can manage user permissions either via the console, the Scaleway APIs or SQL. Managed Database for PostgreSQL and MySQL provides a simplified and unified permission model through the API and the console to make things easier to manage and understand.

Each user has associated permissions that give them access to zero or more logical databases. These include:

  • None: No access to the database
  • Read: Allow users to read tables and fields in a database
  • Write: Allow users to write content in databases.
  • Admin: Read and write access to the data, and extended privileges depending on the database engine.
GET
/rdb/v1/regions/{region}/instances/{instance_id}/privileges
PUT
/rdb/v1/regions/{region}/instances/{instance_id}/privileges

Users

Users are profiles to which you can attribute database-level permissions. They allow you to define permissions specific to each type of database usage. For example, users with an admin role can create new databases and users.

GET
/rdb/v1/regions/{region}/instances/{instance_id}/users
POST
/rdb/v1/regions/{region}/instances/{instance_id}/users
PATCH
/rdb/v1/regions/{region}/instances/{instance_id}/users/{name}
DELETE
/rdb/v1/regions/{region}/instances/{instance_id}/users/{name}

Databases

Databases can be used to store and manage sets of structured information, or data. The interaction between the user and a database is done using a Database Engine, which provides a structured query language to add, modify or delete information from the database.

GET
/rdb/v1/regions/{region}/instances/{instance_id}/databases
POST
/rdb/v1/regions/{region}/instances/{instance_id}/databases
DELETE
/rdb/v1/regions/{region}/instances/{instance_id}/databases/{name}

NodeTypes

Two node type ranges are available:

  • General Purpose: production-grade nodes designed for scalable database infrastructures.
  • Development: sandbox environments and reliable performance for development and testing purposes.
GET
/rdb/v1/regions/{region}/node-types

Snapshots

A snapshot is a consistent, instantaneous copy of the Block Storage volume of your Database Instance at a certain point in time. They are designed to recover your data in case of failure or accidental alterations of the data by a user. They allow you to quickly create a new Instance from a previous state of your database, regardless of the size of the volume. Their limitation is that, unlike backups, snapshots can only be stored in the same location as the original data.

POST
/rdb/v1/regions/{region}/instances/{instance_id}/snapshots
GET
/rdb/v1/regions/{region}/snapshots
GET
/rdb/v1/regions/{region}/snapshots/{snapshot_id}
PATCH
/rdb/v1/regions/{region}/snapshots/{snapshot_id}
DELETE
/rdb/v1/regions/{region}/snapshots/{snapshot_id}
POST
/rdb/v1/regions/{region}/snapshots/{snapshot_id}/create-instance

Endpoints

A point of connection to a Database Instance. The endpoint is associated with an IPv4 address and a port. It contains the information about whether the endpoint is read-write or not. The endpoints always point to the main node of a Database Instance.

All endpoints have TLS enabled. You can use TLS to make your data and your passwords unreadable in transit to anyone but you.

For added security, you can set up ACL rules to restrict access to your endpoint to a set of trusted hosts or networks of your choice.

Load Balancers are used to forward traffic to the right node based on the node state (active/hot standby). The Load Balancers' configuration is set to cut off inactive connections if no TCP traffic is sent within a 6-hour timeframe. We recommend using connection pooling on the application side to renew database connections regularly.

GET
/rdb/v1/regions/{region}/endpoints/{endpoint_id}
DELETE
/rdb/v1/regions/{region}/endpoints/{endpoint_id}
POST
/rdb/v1/regions/{region}/endpoints/{endpoint_id}/migrate
POST
/rdb/v1/regions/{region}/instances/{instance_id}/endpoints
© 2023-2024 – Scaleway