This is an optional step that seeks to simplify your usage of the APIs.
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 dedicated concepts page to find definitions of the different terms referring to Managed Database for PostgreSQL and MySQL.
Quickstart
-
Configure your environment variables.
Noteexport SCW_ACCESS_KEY="<API access key>"export SCW_SECRET_KEY="<API secret key>"export SCW_REGION="<Scaleway region>" -
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": "sbs_5k","volume_size": "30000000000"}'Parameter Description project_id
The ID of the Project you want to create your Database Instance in. To find your Project ID you can list the projects or consult the Scaleway console. engine
REQUIRED 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
name
Name of the Database Instance node_type
REQUIRED 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_cluster
BOOLEAN Defines whether High Availability is enabled for the Database Instance disable_backup
BOOLEAN Defines whether automated backups are disabled for the Database Instance tags
The list of tags ["tag1", "tag2", ...]
that will be associated with the Database Instance. Tags can be appended to the query of the List Database Instances 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_name
REQUIRED Identifier of the default user, which is created concurrently with the Database Instance password
REQUIRED Password for the default user volume_type
Type of volume where data is stored. You can specify either local volume ( lssd
) or block volume (bssd
,sbs_5k
orsbs_15k
). The default value islssd
volume_size
Volume size when volume_type is bssd
,sbs_5k
orsbs_15k
. The value should be expressed in bytes. For example 30GB is expressed as 30000000000 -
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": "sbs_5k","volume_size": "30000000000"}' -
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/instancesYou should get a response like the following:
NoteThis 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": "sbs_5k","size": 30000000000}"created_at": "2019-04-19T16:24:52.591417Z","region": "fr-par"} -
Retrieve your Database Instance IP and port from the response.
NoteIn the example above, the IP and port are
198.51.100.0
and22245
, respectively. -
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 rdbFor the recurring example, the command would look like:
psql -h 198.51.100.0 -p 22245 -U my_initial_user -d rdb -
Enter the database password that you defined upon creation.
You are now connected to your Managed Database.
To perform the following steps, you must first ensure that:
- you have an account and are logged into the Scaleway console
- you have created an API key and that the API key has sufficient IAM permissions to perform the actions described on this page.
- you have installed
curl
Technical Information
Regions
Scaleway's infrastructure is spread across different regions and Availability Zones.
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 Managed Database for PostgreSQL and MySQL FAQ page 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 InnoDB engine is supported
- the Global Transaction Identifier (GTID) is enabled.
mysql_native_password
(default) andcaching_sha2_password
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 haveCREATEROLE
andCREATEDB
privileges. - users do NOT have
SUPERUSER
norREPLICATION
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:
- Managed Database for PostgreSQL and MySQL Documentation
- Managed Database for PostgreSQL and MySQL FAQ
- Scaleway Slack Community join the #database channel
- Contact our support team
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 Migrating existing databases to a Database Instance 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 upgrade your node type or clear out space in your volume.
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
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 delete a Database Instance endpoint 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 list available database engines 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