# Exoscale Documentation — DBaaS > Database as a Service (DBaaS): fully managed data stores on demand, with automated backups and fail-over, European data residency and up to 99.99% SLA. --- url: https://community.exoscale.com/product/dbaas/ --- # DBaaS - [Quick Start - DBaaS](https://community.exoscale.com/product/dbaas/quick-start/index.md) - Get started quickly with a guided setup to achieve your first successful use of the service, including the required steps and configuration. - [Overview - DBaaS](https://community.exoscale.com/product/dbaas/overview/index.md) - Terminology and key features at a glance, learn the core concepts, capabilities, and options of this service before you dive deeper. - [How-To - DBaaS](https://community.exoscale.com/product/dbaas/how-to/index.md) - Step-by-step guides to configure the service and use specific features, with clear instructions for common tasks and problem solving. - [Service Boundaries - DBaaS](https://community.exoscale.com/product/dbaas/service-boundaries/index.md) - Service boundaries: quotas, limits, and the guaranteed service levels (SLA) for this product, including key constraints to plan and operate reliably. - [Reference - DBaaS](https://community.exoscale.com/product/dbaas/reference/index.md) - Reference documentation for API, CLI, and tools, browse comprehensive details, parameters, commands, and integration notes. - [Service-Specific](https://community.exoscale.com/product/dbaas/service-specific/index.md) - Managed PostgreSQL, MySQL, Kafka, OpenSearch, Valkey, Grafana and Thanos for secure, scalable open-source databases and analytics. - [PostgreSQL](https://community.exoscale.com/product/dbaas/service-specific/postgresql/index.md) - A powerful open-source relational database known for reliability, advanced SQL support, extensibility, and strong performance at any scale. - [MySQL](https://community.exoscale.com/product/dbaas/service-specific/mysql/index.md) - MySQL is a popular open-source relational database known for speed, reliability, ease of use, and broad support in web applications. - [Kafka](https://community.exoscale.com/product/dbaas/service-specific/kafka/index.md) - Apache Kafka is a distributed event streaming platform built for high-throughput, fault-tolerant, real-time data pipelines and messaging. - [OpenSearch](https://community.exoscale.com/product/dbaas/service-specific/opensearch/index.md) - OpenSearch is an open-source search and analytics engine for fast querying, full-text search, log analysis, and real-time insights at scale. - [Valkey](https://community.exoscale.com/product/dbaas/service-specific/valkey/index.md) - Valkey is an open-source, in-memory key-value store built for high performance, caching, message brokering, and real-time workloads. - [Grafana](https://community.exoscale.com/product/dbaas/service-specific/grafana/index.md) - Grafana is an open-source observability platform for dashboards, metrics, logs, and traces, enabling real-time monitoring and analysis. - [Thanos](https://community.exoscale.com/product/dbaas/service-specific/thanos/index.md) - Thanos extends Prometheus for long-term storage, global querying, and high availability, enabling scalable and resilient monitoring. - [ClickHouse](https://community.exoscale.com/product/dbaas/service-specific/clickhouse/index.md) - ClickHouse is an open-source, column-oriented database built for real-time analytics and sub-second queries on very large datasets. --- url: https://community.exoscale.com/product/dbaas/quick-start/ --- # Quick Start - DBaaS Launch a fully managed database, message queue, or analytics engine on Exoscale. This quick start guide outlines the minimal steps required to initiate any DBaaS service via the CLI or the Portal. ## Prerequisites - **Exoscale CLI** download the latest (≥ v1.45) binary for macOS, Linux or Windows from [GitHub](https://github.com/exoscale/cli/releases/latest). - **API Key/Secret** configured via the CLI with `exo config`. - **Exoscale Account** sign in or [register](https://portal.exoscale.com/register). ## First Steps via CLI This quick start guide will demonstrate how to create a first service via the CLI for Managed PostgreSQL, but the method is valid for all DBaaS service types. ### Bootstrap Instructions First, verify that the CLI is working correctly. You can do this by listing the DBaaS service types available with the command: ```bash exo dbaas type list ``` ```bash ┼────────────┼────────────────────┼─────────────────┼ │ NAME │ AVAILABLE VERSIONS │ DEFAULT VERSION │ ┼────────────┼────────────────────┼─────────────────┼ │ pg │ 14, 15, 16, 17 │ 16 │ │ opensearch │ 1, 2 │ 2 │ │ kafka │ 3.8, 3.9 │ 3.8 │ │ valkey │ │ - │ │ grafana │ │ - │ │ mysql │ 8 │ 8 │ ┼────────────┼────────────────────┼─────────────────┼ ``` Then per service, you can list the plans available: ```bash exo dbaas type show pg --plans ``` Output: ```bash ┼──────────────────┼─────────┼────────┼─────────────┼────────────┼────────────┼ │ NAME │ # NODES │ # CPUS │ NODE MEMORY │ DISK SPACE │ AUTHORIZED │ ┼──────────────────┼─────────┼────────┼─────────────┼────────────┼────────────┼ │ startup-8 │ 1 │ 4 │ 8.6 GB │ 188 GB │ true │ │ startup-64 │ 1 │ 12 │ 69 GB │ 805 GB │ false │ │ startup-4 │ 1 │ 2 │ 4.3 GB │ 86 GB │ true │ │ startup-32 │ 1 │ 8 │ 34 GB │ 537 GB │ true │ │ startup-225 │ 1 │ 24 │ 242 GB │ 1.4 TB │ false │ │ startup-16 │ 1 │ 4 │ 17 GB │ 376 GB │ true │ │ startup-128 │ 1 │ 16 │ 137 GB │ 1.1 TB │ false │ │ so-startup-64 │ 1 │ 12 │ 69 GB │ 2.1 TB │ false │ │ so-startup-32 │ 1 │ 8 │ 34 GB │ 1.0 TB │ false │ │ so-startup-225 │ 1 │ 24 │ 242 GB │ 7.2 TB │ false │ │ so-startup-128 │ 1 │ 16 │ 137 GB │ 4.1 TB │ false │ │ so-premium-64 │ 3 │ 12 │ 69 GB │ 2.1 TB │ false │ │ so-premium-32 │ 3 │ 8 │ 34 GB │ 1.0 TB │ false │ │ so-premium-225 │ 3 │ 24 │ 242 GB │ 7.2 TB │ false │ │ so-premium-128 │ 3 │ 16 │ 137 GB │ 4.1 TB │ false │ │ so-business-64 │ 2 │ 12 │ 69 GB │ 2.1 TB │ false │ │ so-business-32 │ 2 │ 8 │ 34 GB │ 1.0 TB │ false │ │ so-business-225 │ 2 │ 24 │ 242 GB │ 7.2 TB │ false │ │ so-business-128 │ 2 │ 16 │ 137 GB │ 4.1 TB │ false │ │ premium-8 │ 3 │ 4 │ 8.6 GB │ 188 GB │ true │ │ premium-64 │ 3 │ 12 │ 69 GB │ 805 GB │ false │ │ premium-4 │ 3 │ 2 │ 4.3 GB │ 86 GB │ true │ │ premium-32 │ 3 │ 8 │ 34 GB │ 537 GB │ true │ │ premium-225 │ 3 │ 24 │ 242 GB │ 1.4 TB │ false │ │ premium-16 │ 3 │ 4 │ 17 GB │ 376 GB │ true │ │ premium-128 │ 3 │ 16 │ 137 GB │ 1.1 TB │ false │ │ hobbyist-2 │ 1 │ 2 │ 2.1 GB │ 8.6 GB │ true │ │ cpu-startup-64 │ 1 │ 32 │ 69 GB │ 913 GB │ false │ │ cpu-startup-32 │ 1 │ 16 │ 34 GB │ 698 GB │ false │ │ cpu-startup-16 │ 1 │ 8 │ 17 GB │ 483 GB │ false │ │ cpu-startup-128 │ 1 │ 40 │ 137 GB │ 1.2 TB │ false │ │ cpu-premium-64 │ 3 │ 32 │ 69 GB │ 913 GB │ false │ │ cpu-premium-32 │ 3 │ 16 │ 34 GB │ 698 GB │ false │ │ cpu-premium-16 │ 3 │ 8 │ 17 GB │ 483 GB │ false │ │ cpu-premium-128 │ 3 │ 40 │ 137 GB │ 1.2 TB │ false │ │ cpu-business-64 │ 2 │ 32 │ 69 GB │ 913 GB │ false │ │ cpu-business-32 │ 2 │ 16 │ 34 GB │ 698 GB │ false │ │ cpu-business-16 │ 2 │ 8 │ 17 GB │ 483 GB │ false │ │ cpu-business-128 │ 2 │ 40 │ 137 GB │ 1.2 TB │ false │ │ business-8 │ 2 │ 4 │ 8.6 GB │ 188 GB │ true │ │ business-64 │ 2 │ 12 │ 69 GB │ 805 GB │ false │ │ business-4 │ 2 │ 2 │ 4.3 GB │ 86 GB │ true │ │ business-32 │ 2 │ 8 │ 34 GB │ 537 GB │ true │ │ business-225 │ 2 │ 24 │ 242 GB │ 1.4 TB │ false │ │ business-16 │ 2 │ 4 │ 17 GB │ 376 GB │ true │ │ business-128 │ 2 │ 16 │ 137 GB │ 1.1 TB │ false │ ┼──────────────────┼─────────┼────────┼─────────────┼────────────┼────────────┼ ``` ### Create a First Service The sequence below is shown for service `pg` as an example. To create a first service, use the `exo dbaas create` command. The `--help` flag will give all the details on the usage: ```bash exo dbaas create pg hobbyist-2 test-pg --pg-ip-filter 1.2.3.4/32 -z de-fra-1 ``` Output: ```bash Creating Database Service "test-pg"... ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ │ DATABASE SERVICE │ │ ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ │ Zone │ de-fra-1 │ │ Name │ test-pg │ │ Type │ pg │ │ Plan │ hobbyist-2 │ │ Disk Size │ 8.0 GiB │ │ State │ rebuilding │ │ Creation Date │ 2022-06-09 08:26:13 +0000 UTC │ │ Update Date │ 2022-06-09 08:26:13 +0000 UTC │ │ Nodes │ 1 │ │ Node CPUs │ 2 │ │ Node Memory │ 2.0 GiB │ │ Termination Protected │ true │ │ Maintenance │ sunday (11:52:43) │ │ Version │ 14 │ │ Backup Schedule │ 08:19 │ │ URI │ postgres://avnadmin:xxxxx@test-pg-exoscale-980a712f-5c76-4ec4-a3bc-4e4e442deef2.aivencloud.com:21699/defaultdb?sslmode=require │ │ IP Filter │ 1.2.3.4/32 │ │ Components │ │ │ │ pg test-pg-exoscale-980a712f-5c76-4ec4-a3bc-4e4e442deef2.aivencloud.com:21699 route:dynamic usage:primary │ │ │ pgbouncer test-pg-exoscale-980a712f-5c76-4ec4-a3bc-4e4e442deef2.aivencloud.com:21700 route:dynamic usage:primary │ │ │ │ │ Users │ n/a │ ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ ``` *PS1: from now on add the `-z ` flag to manage this DB instance* *PS2: your organization is limited to 3 DBaaS services total by default. Contact our Support team if you encounter the message `Usage of resource 'dbaas' has been exceeded.`* ## First Steps via Portal This quick start guide will demonstrate how to create a first service via the Portal for Managed PostgreSQL, but the steps shown are valid for all DBaaS service types. ### Add a Service in Portal Navigate to the [DBaaS view](https://portal.exoscale.com/dbaas): ![](dbaas-menu.png "Exoscale DBaaS navigation menu") Select the service type you want to add from the `...` menu at the top right header. For example, here for a [Managed PostgreSQL](https://portal.exoscale.com/dbaas/add/pg) ![](dbaas-select-service.png "Exoscale DBaaS select service dropdown") Enter the name, and select the zone location and service plan. click on `Create` to launch the service. ![](dbaas-add-pg-service.png "Exoscale DBaaS add PostgreSQL service") ### Use Your Service in Portal The connection details such as the `user`, `password` or `certificate` and `URI` are available from connection data table in the service detail page. ![](dbaas-details-pg-service.png "Exoscale DBaaS details PostgreSQL service") Copy these details into a database client or application to start interacting with the database and create tables. Continue to the [overview](https://community.exoscale.com/product/dbaas/overview/index.md) section for the next steps with DBaaS. ## Next Steps Learn more about the Exoscale DBaaS architecture and concepts in the [overview](https://community.exoscale.com/product/dbaas/overview/index.md). Then, prepare general topics in the [how-to](https://community.exoscale.com/product/dbaas/how-to/index.md) section. You can then access the specific details of each service in the following sections: - [Managed Grafana](https://community.exoscale.com/product/dbaas/service-specific/grafana/index.md) - [Managed Kafka](https://community.exoscale.com/product/dbaas/service-specific/kafka/index.md) - [Managed MySQL](https://community.exoscale.com/product/dbaas/service-specific/mysql/index.md) - [Managed OpenSearch](https://community.exoscale.com/product/dbaas/service-specific/opensearch/index.md) - [Managed PostgreSQL](https://community.exoscale.com/product/dbaas/service-specific/postgresql/index.md) - [Managed Thanos](https://community.exoscale.com/product/dbaas/service-specific/thanos/index.md) - [Managed Valkey](https://community.exoscale.com/product/dbaas/service-specific/valkey/index.md) --- url: https://community.exoscale.com/product/dbaas/overview/ --- # Overview - DBaaS Exoscale’s __Database as a Service (DBaaS)__ enables you to quickly deploy fully managed data stores on demand. Our service is supported by enterprise-grade automation, ensures European data residency, and offers clusters with up to 99.99% uptime Service Level Agreements (SLAs). ## Architecture Exoscale DBaaS provisions **dedicated virtual machines** per service; no compute resources are shared across organizations, and the servers never appear in your public instance list — they live behind a managed endpoint that Exoscale operates for you. Each plan changes *how many* of those isolated nodes are launched (single-node for Hobbyist/Startup, multi-node clusters for Business/Premium). Under the hood, a European control plane (powered by our partner **Aiven**) orchestrates day-to-day operations: creation, daily backups, automated fail-over, rolling upgrades, and health checks. Traffic between nodes and to the object storage is encrypted, and all data remains inside the zone-country you selected. Because every service has dedicated VMs, you can resize, fork, or terminate it without affecting any other customer. After internal fail-over, the endpoint’s DNS name stays the same, so clients only need basic reconnect logic. > [!NOTE] > Use the plan naming scheme (`-x?-`) to know instantly > how many dedicated nodes and RAM each deployment receives. ### Naming Conventions A DBaaS plan name tells you **three key facts** about the service without opening a table: | Segment | Example | Meaning | | :--- | :---: | :--- | | **Tier** | `premium` | Redundancy & backup profile (Hobbyist ---> Premium) | | **Node Count** | `9x` | Number of nodes in the cluster (omitted on single-node plans) | | **RAM per Node** | `16` | Memory in GB for *each* node; aligns with Exoscale Compute flavors | ### Reading a Plan *`premium-9x-16`* ---> Premium-tier cluster, **9** nodes, **16 GB** RAM each. ### Tier Quick Reference - **Hobbyist** single node, no SLA, hourly backup (1 copy) - **Startup** single node, 99.95 % SLA, hourly + rolling 3-day daily backups - **Business** 2 nodes, hourly + 14-day retention, 99.99 % SLA - **Premium** 3 nodes, hourly + 30-day retention, 99.99 % SLA Details (CPU, storage, price) live in the [DBaaS plan tables](https://www.exoscale.com/dbaas/). ### Why the Pattern? The scheme is shared by all engines (`pg`, `mysql`, `kafka`, `opensearch`, `valkey`, `grafana`, `thanos`) so teams can: - **Spot Capacity** larger last number = more RAM - **Spot Resilience** higher tier = more replicas/backups - **Compare Costs** same tier & size behave similarly across zones > [!NOTE] > when creating or updating a service via CLI/API, the `plan-string` is the only argument > you need to switch hardware, redundancy or price class. ### Service Levels Most DBaaS plans have a guaranteed **Service Level Agreement (SLA)** for high availability and reliability. - **Hobbyist** plans have no SLA (best effort, no service credits) - **Startup** plans provide **99.95%** availability - **Business** and **Premium** plans provide **99.99%** availability The SLA applies to the uptime and responsiveness of the managed database services. It ensures that services remain accessible and functional according to enterprise-grade standards. Failures beyond this threshold are eligible for compensation as defined in the [Exoscale's SLAs](https://www.exoscale.com/terms/#:~:text=4.%20Service%20Level%20Agreement%20(SLA)). > [!NOTE] > The SLA applies only to the service infrastructure and not to user data, applications, or queries running on the databases. ## Terminology Exoscale DBaaS : A managed database as a service provided by Exoscale, which allows users to deploy and manage databases without managing the underlying infrastructure. Plans : Exoscale offers various plans for their DBaaS solutions, including Hobbyist, Startup, Business, and Premium, each catering to different workload requirements and scales. Database Forking : Available in some plans, allowing users to create a duplicate of a database for testing or development purposes without affecting the production environment. Dedicated Instances : All Exoscale managed databases run on dedicated instances, ensuring resources are not shared with other clients, which improves performance and security. Volume Size : Refers to the storage capacity allocated for a database instance, which varies depending on the plan and can be adjusted to match the application needs. Max Connections : The maximum number of connections a database can handle at any time, which is set according to the chosen plan. Data Replication : Exoscale ensures data replication within its infrastructure to maintain data integrity and availability. Daily Backups : All plans include daily backups, securing data and providing a restore point in the case of failure or data loss. Zones : Exoscale DBaaS solutions are available across multiple zones, providing options for geographic distribution and high availability. ## Features Managed Lifecycle : provisioning, patching, auto-healing and upgrades are handled by Exoscale. Automated Backups : daily encrypted backups retained per-plan policy; point-in-time-recovery available on engines that support it. High Availability Options : from single-node *Hobbyist* to multi-node *Premium* clusters with synchronous replication. Security by Design : services are isolated on dedicated instances and reachable only via TLS-encrypted endpoints; IP filters control ingress. Automation : full API & CLI coverage, plus Terraform provider SLAs : Startup 99.95 %, Business & Premium 99.99 %; Hobbyist has no SLA. --- url: https://community.exoscale.com/product/dbaas/how-to/ --- # How-To - DBaaS Step-by-step guides to configure the service and use specific features, with clear instructions for common tasks and problem solving. - [Connect to a Database](https://community.exoscale.com/product/dbaas/how-to/connect-db/index.md) - Connect to an Exoscale DBaaS database by retrieving its URI, verifying service status, using client tools, and managing deletion protection. - [Use External Integrations](https://community.exoscale.com/product/dbaas/how-to/external-integrations/index.md) - Use external integrations to connect Exoscale DBaaS with Datadog, Prometheus, logging, and analytics tools for monitoring and observability. - [Manage Backups and Restores](https://community.exoscale.com/product/dbaas/how-to/backups-restore/index.md) - Manage DBaaS backups and restores with automated backups, PITR, fork-based recovery, upgrade workflows, and termination protection. - [Manage Maintenance Windows](https://community.exoscale.com/product/dbaas/how-to/maintenance-windows/index.md) - Manage DBaaS maintenance windows to schedule updates during low-traffic periods and understand rolling upgrades and failover behavior. - [Scale DBaaS Services](https://community.exoscale.com/product/dbaas/how-to/scaling/index.md) - Scale DBaaS services between supported plans to increase or reduce capacity, provided lower plans still meet current storage requirements. - [Sync SKS IP Filters](https://community.exoscale.com/product/dbaas/how-to/sks-ip-filter/index.md) - Sync DBaaS IP filters with SKS node IPs automatically to restrict database access to cluster nodes as nodes scale, change, or get replaced. - [Use Terraform for DBaaS](https://community.exoscale.com/product/dbaas/how-to/terraform/index.md) - Use Terraform to provision and manage Exoscale DBaaS services like PostgreSQL, MySQL, Kafka, Valkey, Grafana, OpenSearch, and ClickHouse. --- url: https://community.exoscale.com/product/dbaas/how-to/connect-db/ --- # Connect to a Database To connect to your DB instance, you need to retrieve your credentials: ```bash exo dbaas -z de-fra-1 show test-pg --uri ``` Output: ```bash postgres://avnadmin:AVNS_SbyJOj29FaxJHa4XJEj@test-pg-exoscale-980a712f-5c76-4ec4-a3bc-4e4e442deef2.aivencloud.com:21699/defaultdb?sslmode=require ``` The status of your DB instance should have changed from **rebuilding** after the `create` command to **running**. To check: ```bash exo dbaas show test-pg -z de-fra-1 ``` Output: ```bash ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ │ DATABASE SERVICE │ │ ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ │ Zone │ de-fra-1 │ │ Name │ test-pg │ │ Type │ pg │ │ Plan │ hobbyist-2 │ │ Disk Size │ 8.0 GiB │ │ State │ rebuilding │ │ Creation Date │ 2022-06-09 08:26:13 +0000 UTC │ │ Update Date │ 2022-06-09 08:27:25 +0000 UTC │ │ Nodes │ 1 │ │ Node CPUs │ 2 │ │ Node Memory │ 2.0 GiB │ │ Termination Protected │ true │ │ Maintenance │ sunday (11:52:43) │ │ Version │ 14 │ │ Backup Schedule │ 08:19 │ │ URI │ postgres://avnadmin:xxxxx@test-pg-exoscale-980a712f-5c76-4ec4-a3bc-4e4e442deef2.aivencloud.com:21699/defaultdb?sslmode=require │ │ IP Filter │ 1.2.3.4/32 │ │ Components │ │ │ │ pg test-pg-exoscale-980a712f-5c76-4ec4-a3bc-4e4e442deef2.aivencloud.com:21699 route:dynamic usage:primary │ │ │ pgbouncer test-pg-exoscale-980a712f-5c76-4ec4-a3bc-4e4e442deef2.aivencloud.com:21700 route:dynamic usage:primary │ │ │ │ │ Users │ n/a │ ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ ``` You can now connect to the database engine: ```bash psql ``` Output: ```bash postgres://avnadmin:AVNS_SbyJOj29FaxJHa4XJEj@test-pg-exoscale-980a712f-5c76-4ec4-a3bc-4e4e442deef2.aivencloud.com:21699/defaultdb?sslmode=require psql (9.2.24, server 14.3) WARNING: psql version 9.2, server version 14.0. Some psql features might not work. SSL connection (cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256) Type "help" for help. defaultdb=> \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+-------------+-------------+----------------------- _aiven | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =T/postgres + | | | | | postgres=CTc/postgres defaultdb | avnadmin | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres (4 rows) defaultdb=> ``` #### Other Commands In addition to the creation commands listed above, you will find: - List: `exo dbaas list` - Delete: `exo dbaas delete test-pg -z de-fra-1` The update command will enable you to adjust parameters of a DB instance. ##### Disable Termination Protection ```bash exo dbaas update test-pg -z de-fra-1 --termination-protection=false ``` Output: ```bash Updating Database Service "test-pg"... ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ │ DATABASE SERVICE │ │ ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ │ Zone │ de-fra-1 │ │ Name │ test-pg │ │ Type │ pg │ │ Plan │ hobbyist-2 │ │ Disk Size │ 8.0 GiB │ │ State │ running │ │ Creation Date │ 2022-06-09 08:26:13 +0000 UTC │ │ Update Date │ 2022-06-09 08:40:16 +0000 UTC │ │ Nodes │ 1 │ │ Node CPUs │ 2 │ │ Node Memory │ 2.0 GiB │ │ Termination Protected │ false │ │ Maintenance │ sunday (11:52:43) │ │ Version │ 14.3 │ │ Backup Schedule │ 08:19 │ │ URI │ postgres://avnadmin:xxxxx@test-pg-exoscale-980a712f-5c76-4ec4-a3bc-4e4e442deef2.aivencloud.com:21699/defaultdb?sslmode=require │ │ IP Filter │ 1.2.3.4/32 │ │ Components │ │ │ │ pg test-pg-exoscale-980a712f-5c76-4ec4-a3bc-4e4e442deef2.aivencloud.com:21699 route:dynamic usage:primary │ │ │ pgbouncer test-pg-exoscale-980a712f-5c76-4ec4-a3bc-4e4e442deef2.aivencloud.com:21700 route:dynamic usage:primary │ │ │ │ │ Users │ avnadmin (primary) │ ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ ``` It is now possible to delete the instance: ```bash exo dbaas -z de-fra-1 delete test-pg ``` Output: ```bash [+] Are you sure you want to delete Database Service "test-pg"? [yN]: y ✔ Deleting Database Service "test-pg"... 0s ``` Otherwise, you will get the following error: ```bash exo dbaas -z de-fra-1 delete test-pg ``` Output: ```bash [+] Are you sure you want to delete Database Service "test-pg"? [yN]: y ✔ Deleting Database Service "test-pg"... 0s error: Delete "https://api-de-fra-1.exoscale.com/v2/dbaas-service/test-pg": invalid request: The service is protected against termination and shutdown. Remove termination protection first. ``` Other global parameters currently supported include: - Maintenance day of the week - Maintenance time slot --- url: https://community.exoscale.com/product/dbaas/how-to/external-integrations/ --- # Use External Integrations External integrations allow you to connect your Exoscale DBaaS services with third-party monitoring, logging, or analytics tools. ### Prerequisites - Exoscale CLI version **1.79.1** (can be done via the [Exoscale Portal](https://portal.exoscale.com/) as well.) - If you need to install or upgrade, follow the [Exoscale CLI installation guide](https://community.exoscale.com/tools/command-line-interface/index.md). - Necessary permissions: Ensure you have the required permissions to manage integrations on the selected DBaaS service. - API credentials or endpoint details: Obtain the necessary API credentials or endpoint details for the external service you want to integrate (e.g., Datadog API key, Prometheus URL,...). ### Step 1: Create an External Endpoint Before attaching an external integration, you need to create an external endpoint. This endpoint represents the connection to the third-party service (e.g., Datadog, Prometheus). #### Example: Create a Datadog Endpoint Run the following command to create a Datadog endpoint: ```bash exo dbaas external-endpoint create datadog datadog-endpoint --datadog-api-key eebc5889bae019cb758863df38b9a19a --datadog-site datadoghq.eu ``` #### Explanation of the Command - `exo dbaas external-endpoint create datadog`: Creates a Datadog endpoint. - `datadog-endpoint`: A human-readable name for the endpoint. - `--datadog-api-key eebc5889bae019cb758863df38b9a19a`: Your Datadog API key for authentication. - `--datadog-site datadoghq.eu`: Specifies the Datadog site (e.g., `datadoghq.eu` for EU region). After running the command, you’ll receive an **Endpoint ID** (e.g., `2da0a841-5314-47f2-8bfe-2856acea17e0`). Save this ID for the next step. ### Step 2: Attach the External Integration Once the endpoint is created, you can attach it to your DBaaS service using the `exo dbaas external-integration attach` command. #### Example: Attach Datadog to a PostgreSQL Service Run the following command to attach the Datadog integration to a PostgreSQL service named `rocket-pg`: ```bash exo dbaas external-integration attach datadog --source-service-name rocket-pg --destination-endpoint-id 2da0a841-5314-47f2-8bfe-2856acea17e0 ``` #### Result The integration will be established, and your database service will send relevant metrics to Datadog. Verify the integration within your Datadog dashboard. ### Step 3: Verify the Integration After attaching the integration, verify its status by listing all external integrations for your DBaaS service: ```bash exo dbaas external-integration list rocket-pg ``` This command will display a list of all external integrations attached to the `rocket-pg` service, including their status and endpoint details. ### Step 4: Manage Datadog Integration Settings You need to update the Datadog integration settings to enable advanced monitoring features like `pg_stat` and `pgbouncer` for PostgreSQL services. #### Prerequisites for Advanced Monitoring Enable Required Extensions: Ensure the following extensions are enabled in your PostgreSQL service: ```sql CREATE EXTENSION pg_stat_statements; CREATE EXTENSION aiven_extras; ``` #### Show Datadog Integration Settings To view the current settings of a Datadog integration, use the following command: ```bash exo dbaas external-integration settings show datadog 2875dd0e-2107-4c5d-93d2-1f7581860e1e ``` Replace `2875dd0e-2107-4c5d-93d2-1f7581860e1e` with the actual integration UUID. #### Enable Advanced Monitoring Features To enable `pg_stat` and `pgbouncer` monitoring, update the Datadog integration settings with the following command: ```bash exo dbaas external-integration settings update datadog 2875dd0e-2107-4c5d-93d2-1f7581860e1e --datadog-dbm-enabled true --datadog-pgbouncer-enabled true ``` #### Explanation of the Command - `--datadog-dbm-enabled true`: Enables Database Monitoring (DBM) for advanced metrics. - `--datadog-pgbouncer-enabled true`: Enables PgBouncer monitoring for connection pooling metrics. ### Step 5: Detach an External Integration (Optional) If you no longer need an external integration, you can detach it using the following command: ```bash exo dbaas external-integration detach rocket-pg --integration-id 2875dd0e-2107-4c5d-93d2-1f7581860e1e ``` ### Supported External Integrations Exoscale DBaaS supports the following external integrations: - **Datadog**: For monitoring and analytics. - **Rsyslog**: For log forwarding. - **Prometheus**: For time-series monitoring. - **Elasticsearch**: For log and event data analysis. - **OpenSearch**: For search and analytics. #### Example configuration for Prometheus 1. Create an Endpoint for Prometheus Integration - Name can be anything, it doesn't need to be the Prometheus URL. - Username is the Username which will be later be used to scrape the data from DBaaS. - Password is the Password which will be later be used to scrape the data from DBaaS. Please store the password as you can't retrieve it later. 2. Attach the new Endpoint to your DBaaS Service 3. Get the CA certifcate from the DBaaS Service from the connection details and transfer it to your prometheus instance. 4. Get the prometheus URI for the DBaaS Service from the connection details. 5. Add the IP from Prometheus to the IP Filter for the DBaaS Service. 6. Add scrape info to Prometheus ```bash - job_name: aivenmetrics scheme: https basic_auth: username: "" password: "" tls_config: ca_file: static_configs: - targets: [""] ``` ### Troubleshooting If you encounter issues while creating endpoints or attaching integrations: - Verify that you have the necessary permissions and correct API credentials or endpoint details. - Check the [Exoscale Platform Status](https://exoscalestatus.com/) page for any ongoing incidents. For further assistance, contact [Exoscale Support Plans](https://www.exoscale.com/support/). --- url: https://community.exoscale.com/product/dbaas/how-to/backups-restore/ --- # Manage Backups and Restores Exoscale DBaaS are automatically backed up, encrypted and stored securely in Object Storage. The frequency and retention of backups is defined in the plan. Refer to the [plan tables](https://www.exoscale.com/dbaas/) to review the specifications of each plan. You can also check the specific plan backup strategy with the command: ```bash exo dbaas type show pg --backup-config startup-8 ``` Output: ```bash ┼────────────────────────────┼──────┼ │ Backup interval (hours) │ 24 │ │ Max backups │ 3 │ │ Recovery mode │ pitr │ │ Frequent backup interval │ n/a │ │ Frequent backup max age │ n/a │ │ Infrequent backup interval │ n/a │ │ Infrequent backup max age │ n/a │ ┼────────────────────────────┼──────┼ ``` Some services like `pg` include PITR (point in time recovery) which enables you to restore data at any time between 2 backup intervals. Exoscale DBaaS does not allow you to restore data over an existing running service. Instead, you can create a new service from an existing service specifying the time of recovery you need in order to restore data. This operation is called a **fork**. ### Forks Here is an example for `pg` that demonstrates how to create a fork of a service from a previous backup, and how to perform a point-in-time recovery. - Identify the available backups and periods of time available for a fork: ```bash exo dbaas show test-pg -z de-fra-1 --backups ``` Output: ```bash ┼─────────────────────────────────────┼───────────────────────────────┼──────────┼ │ NAME │ DATE │ SIZE │ ┼─────────────────────────────────────┼───────────────────────────────┼──────────┼ │ 2021-10-30_20-28_0.00000000.pghoard │ 2021-10-30 20:28:01 +0000 UTC │ 36341760 │ │ 2021-10-31_20-28_0.00000000.pghoard │ 2021-10-31 20:28:04 +0000 UTC │ 36382720 │ ┼─────────────────────────────────────┼───────────────────────────────┼──────────┼ ``` - Create a fork with a point-in-time recovery: ```bash exo dbaas create pg startup-4 fork-test-pg --pg-recovery-backup-time 2021-10-30 23:35 --pg-fork-ftest-pg -z de-fra-1 ``` The rest of the create options behave like the normal create command. You can specify options and service-specific options at launch time. Refer to the service specific documentation for additional details. > [!NOTE] > If you need to fork a service specifying another plan size than the original, > note that the storage should be sufficient if you launch the new service with > a smaller plan than the original service or fork. ### Backup Schedule In the example above, we can see that the service is backed up each day at 20:28. This slot can be adjusted for most services, but the process is service specific. Refer to the service specific documentation to change the backup schedule of a service. ## Upgrades Running upgrades will follow the same process as restoring a service from a fork, except that we will only create the service specifying the fork but not the recovery backup time. The service will be created using the latest major and minor supported release of a service type. ## Termination Protection Termination protection will ensure your service is not deleted accidentally by running the `delete` command or any other destructive operation. ```bash exo dbaas update test-pg -z de-fra-1 --termination-protection=true ``` Output: ```bash Updating Database Service "test-pg"... ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ │ DATABASE SERVICE │ │ ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ │ Zone │ de-fra-1 │ │ Name │ test-pg │ │ Type │ pg │ │ Plan │ hobbyist-1 │ │ Disk Size │ 8.0 GiB │ │ State │ running │ │ Creation Date │ 2021-07-05 08:38:39 +0000 UTC │ │ Update Date │ 2021-10-21 08:30:54 +0000 UTC │ │ Nodes │ 1 │ │ Node CPUs │ 2 │ │ Node Memory │ 2.0 GiB │ │ Termination Protected │ true │ │ Maintenance │ sunday (10:40:38) │ │ Backup Schedule │ 12:52 │ │ URI │ postgres://avnadmin:xxxxx@test-pg-exoscale-08b0165e-ef03-47ec-926f-f01163d557ed.aivencloud.com:21699/defaultdb?sslmode=require │ │ IP Filter │ 0.0.0.0/0 │ │ Components │ │ │ │ pg test-pg-exoscale-08b0165e-ef03-47ec-926f-f01163d557ed.aivencloud.com:21699 route:dynamic usage:primary │ │ │ pgbouncer test-pg-exoscale-08b0165e-ef03-47ec-926f-f01163d557ed.aivencloud.com:21700 route:dynamic usage:primary │ │ │ │ │ Users │ avnadmin (primary) │ ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ ``` It is therefore not possible to delete the service. If you decide to delete the service once termination protection is enabled: ```bash exo dbaas -z de-fra-1 delete test-pg ``` Output: ```bash [+] Are you sure you want to delete Database Service "test-pg"? [yN]: y ✔ Deleting Database Service "test-pg"... 0s error: Delete "https://api-de-fra-1.exoscale.com/v2/dbaas-service/test-pg": invalid request: The service is protected against termination and shutdown. Remove termination protectio n first. ``` Revert the flag and then delete the DB instance. --- url: https://community.exoscale.com/product/dbaas/how-to/maintenance-windows/ --- # Manage Maintenance Windows Maintenance windows are used to perform necessary updates and upgrades regarding security and management layers of your Exoscale DBaaS services. They are not used to perform major service version upgrades, refer to the section [upgrades](#upgrades) on how to upgrade versions. > [!NOTE] Urgent upgrades including vulnerability updates will happen before the maintenance window in order to keep the services safe. By default, an arbitrary slot will be assigned when creating your service. You can control the weekly maintenance window of each service to ensure maintenance occurs during a window with lower traffic levels. ### Changing the Maintenance Window of a Service To adapt the maintenance window of a service, you need to pass a new day of week and associated time with the `update` command ```bash exo dbaas update -z de-fra-1 test-pg --maintenance-dow=tuesday --maintenance-time=10:10:10 ``` ```bash Updating Database Service "test-pg"... ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ │ DATABASE SERVICE │ │ ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ │ Zone │ de-fra-1 │ │ Name │ test-pg │ │ Type │ pg │ │ Plan │ hobbyist-1 │ │ Disk Size │ 8.0 GiB │ │ State │ running │ │ Creation Date │ 2021-10-21 08:42:40 +0000 UTC │ │ Update Date │ 2021-11-01 09:25:27 +0000 UTC │ │ Nodes │ 1 │ │ Node CPUs │ 2 │ │ Node Memory │ 2.0 GiB │ │ Termination Protected │ true │ │ Maintenance │ tuesday (10:10:10) │ │ Backup Schedule │ 20:28 │ │ URI │ postgres://avnadmin:xxxxx@test-pg-exoscale-08b0165e-ef03-47ec-926f-f01163d557ed.aivencloud.com:21699/defaultdb?sslmode=require │ │ IP Filter │ 0.0.0.0/0 │ │ Components │ │ │ │ pg test-pg-exoscale-08b0165e-ef03-47ec-926f-f01163d557ed.aivencloud.com:21699 route:dynamic usage:primary │ │ │ pgbouncer test-pg-exoscale-08b0165e-ef03-47ec-926f-f01163d557ed.aivencloud.com:21700 route:dynamic usage:primary │ │ │ │ │ Users │ avnadmin (primary) │ ┼───────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼ ``` The maintenance window can also be specified at creation time with the same parameters. This parameter can also be checked and adjusted within the Portal under the `maintenance` tab of a service. The same tab also lists the upcoming updates to be applied at the next scheduled maintenance or manually within the page. ### How Maintenance and Upgrades Work Upgrades are performed as rolling upgrades where completely new instances are built alongside the old ones. After the new instances are running and synced with the old instances, a controlled automatic failover is performed to switch the service to use the new upgraded instances. The old servers are retired automatically after the new instances have taken over for providing the service. The controlled failover is very quick and safe - it takes less than a minute to get clients connected again. Typically, we see a 5-10 second period during which the clients are unable to re-establish the connection. Single node plans will however see a longer downtime. Best practices for client configuration: - Do not cache IP addresses of services. - Make sure your client can automatically reconnect to a service. - Make sure the DNS name of a service stays the same after the upgrade. --- url: https://community.exoscale.com/product/dbaas/how-to/scaling/ --- # Scale DBaaS Services You can scale a service from one supported plan to another. ### Scaling Up Scaling to a larger plan is always supported: - within the same plan category: for example, from business-8 to business-16 - from one plan category to another: for example, from startup-8 to business-16 - from one family to another: for example, from startup-32 to cpu-startup32 You can trigger the scale operation with the `update` command: ```bash exo dbaas update -z de-fra-1 test-pg --plan startup-4 ``` Output: ```bash Updating Database Service "test-pg"... ``` ### Scaling Down Scaling down a service is generally supported on all service types, provided the storage requirements of the lower plan will fit the space currently used within your service. From one plan category to another, scaling down is generally supported for non-distributed services like `pg` or `mysql`, as it will remove one replica from the replica set. For example, scaling down from premium-32 to business-32 will remove one replica only. --- url: https://community.exoscale.com/product/dbaas/how-to/sks-ip-filter/ --- # Sync SKS IP Filters Managed Databases do not yet support security groups. As an alternative, you can run this automation to continuously synchronize your database IP filters with SKS cluster node IPs. The automation monitors node changes (scaling, replacements) and automatically updates the `ip_filter` to restrict database access to your cluster nodes only. **Note:** All connections to Managed Databases are always encrypted with TLS. The IP filter provides an additional layer of access control by restricting which source IPs can connect. **How it works:** The automation fetches node IPs from all configured Kubernetes clusters and updates the IP filter for every configured database. To create separate cluster-to-database pairings, deploy multiple instances (e.g., in different Kubernetes namespaces). **Deployment options:** - **Kubernetes deployment** (covered in this guide) - Using pre-built container images - **Docker** or **VM/local machine** - See the [GitHub repository README](https://github.com/exoscale-labs/sks-sample-manifests/tree/main/exo-k8s-dbaas-filter#quick-start) for alternative deployment methods **Key capabilities:** - Automatically discovers node IPs from one or more SKS clusters - Updates IP filters for multiple databases - Detects node changes at configurable intervals (default: 10 seconds) - Minimal IAM permissions required - Supports multiple deployments for different cluster-to-database pairings or multiple accounts ## Prerequisites - One or more Exoscale SKS clusters - One or more DBaaS services created ## Step 1: Create IAM API Credentials You can do this step either in the Portal or via the CLI. Create a policy file `dbaas-filter-policy.json` with least-privilege permissions: ```json { "default-service-strategy": "deny", "services": { "dbaas": { "type": "rules", "rules": [ { "expression": "operation in ['list-dbaas-services', 'get-dbaas-service-pg', 'get-dbaas-service-mysql', 'get-dbaas-service-kafka', 'get-dbaas-service-opensearch', 'get-dbaas-service-valkey', 'get-dbaas-service-grafana', 'get-dbaas-settings-pg', 'get-dbaas-settings-mysql', 'get-dbaas-settings-kafka', 'get-dbaas-settings-opensearch', 'get-dbaas-settings-valkey', 'get-dbaas-settings-grafana']", "action": "allow" }, { "expression": "operation in ['update-dbaas-service-pg', 'update-dbaas-service-mysql', 'update-dbaas-service-kafka', 'update-dbaas-service-opensearch', 'update-dbaas-service-valkey', 'update-dbaas-service-grafana'] && parameters.has('ip_filter') && int(parameters.size()) == 2", "action": "allow" } ] }, "compute": { "type": "rules", "rules": [ { "expression": "operation in ['list-zones', 'list-sks-clusters', 'get-sks-cluster', 'get-instance-pool', 'get-instance']", "action": "allow" } ] } } } ``` This policy only allows: - **Compute**: 5 GET/LIST operations to query SKS cluster nodes - **DBaaS**: Reading database info and updating only the `ip-filter` property Create the IAM role and API key: ```bash exo iam role create dbaas-filter-role \ --description "DBaaS IP filter automation" \ --policy file://dbaas-filter-policy.json exo iam api-key create dbaas-filter-key --role dbaas-filter-role ``` Save the API key and secret from the output. ## Step 2: Download the Deployment Manifests You need the Kubernetes deployment manifests from the [GitHub repository](https://github.com/exoscale-labs/sks-sample-manifests/tree/main/exo-k8s-dbaas-filter). **Option 1: Clone the repository** ```bash git clone https://github.com/exoscale-labs/sks-sample-manifests.git cd sks-sample-manifests/exo-k8s-dbaas-filter ``` **Option 2: Download just the deployment files** Download these two files: - [`deployment.yaml`](https://raw.githubusercontent.com/exoscale-labs/sks-sample-manifests/main/exo-k8s-dbaas-filter/deployment.yaml) - Contains the namespace, ConfigMap, and deployment - [`kustomization.yaml`](https://raw.githubusercontent.com/exoscale-labs/sks-sample-manifests/main/exo-k8s-dbaas-filter/kustomization.yaml) - Kustomize configuration ```bash curl -O https://raw.githubusercontent.com/exoscale-labs/sks-sample-manifests/main/exo-k8s-dbaas-filter/deployment.yaml curl -O https://raw.githubusercontent.com/exoscale-labs/sks-sample-manifests/main/exo-k8s-dbaas-filter/kustomization.yaml ``` ## Step 3: Deploy to Kubernetes ### Create the Secret Create a namespace and secret with your API credentials: ```bash kubectl create namespace exoscale-automation kubectl -n exoscale-automation create secret generic exoscale-api-credentials \ --from-literal=api-key='EXOxxxxxxxxxxxxxxxxxxxxxxxx' \ --from-literal=api-secret='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' ``` ### Configure the Deployment Edit `deployment.yaml` ConfigMap to configure your clusters and databases: ```yaml data: # SKS Clusters to monitor (format: "cluster-name:zone,cluster-name:zone") sks-clusters: "my-cluster:ch-gva-2" # DBaaS services to update (format: "db-name:zone:type,db-name:zone:type") # Supported types: pg, mysql, kafka, opensearch, valkey, grafana dbaas-services: "my-postgres-db:ch-gva-2:pg" # Optional: Static IPs to always include (CIDR format) static-ips: "" # Example: "192.168.1.1/32,10.0.0.0/24" # Check interval in seconds (default: 10) check-interval: "60" # Log level: DEBUG, INFO, WARNING, ERROR (default: INFO) log-level: "INFO" ``` **Configuration examples:** Single cluster with multiple databases: ```yaml sks-clusters: "prod-cluster:ch-gva-2" dbaas-services: "prod-postgres:ch-gva-2:pg,prod-mysql:ch-gva-2:mysql" ``` Multiple clusters with multiple databases: ```yaml sks-clusters: "prod-cluster:ch-gva-2,staging-cluster:de-fra-1" dbaas-services: "prod-postgres:ch-gva-2:pg,prod-kafka:de-fra-1:kafka,staging-mysql:de-fra-1:mysql" ``` ### Deploy Deploy using kustomize: ```bash kubectl apply -k . ``` ### Monitor the Automation Check the logs to verify it's working: ```bash kubectl logs -n exoscale-automation -l app=exo-dbaas-filter -f ``` Expected output: ``` [2025-11-17 10:30:15 UTC] Starting DBaaS IP filter automation [2025-11-17 10:30:15 UTC] Monitoring 1 SKS cluster(s) [2025-11-17 10:30:15 UTC] Managing IP filters for 1 DBaaS service(s) [2025-11-17 10:30:15 UTC] Checking for IP changes... [2025-11-17 10:30:15 UTC] Gathering IPs from all clusters... [2025-11-17 10:30:16 UTC] Querying cluster: my-cluster (zone: ch-gva-2) [2025-11-17 10:30:18 UTC] Found IP: 194.182.169.155 (instance: pool-abc-12345) [2025-11-17 10:30:19 UTC] Found IP: 89.145.162.50 (instance: pool-abc-67890) [2025-11-17 10:30:20 UTC] IP change detected! [2025-11-17 10:30:20 UTC] New IP list: 194.182.169.155/32, 89.145.162.50/32 [2025-11-17 10:30:20 UTC] Updating DBaaS IP filters... [2025-11-17 10:30:21 UTC] Updating pg database: my-postgres-db (zone: ch-gva-2) [2025-11-17 10:30:23 UTC] Update complete. ``` ## Step 4: Verify the IP Filter Verify the IP filter was applied to your database: ```bash exo dbaas show my-postgres-db -z ch-gva-2 ``` The output should show your cluster node IPs in the IP filter field. ## Configuration Reference All configuration is done via environment variables in the ConfigMap: | Variable | Required | Description | Example | | ---------- | ---------- | ------------- | --------- | | `sks-clusters` | Yes | SKS clusters to monitor (comma-separated) | `prod:ch-gva-2,staging:de-fra-1` | | `dbaas-services` | Yes | DBaaS services to update (comma-separated) | `prod-pg:ch-gva-2:pg,prod-mysql:de-fra-1:mysql` | | `static-ips` | No | Additional static IPs to include (comma-separated) | `203.0.113.10/32,198.51.100.0/24` | | `check-interval` | No | Check interval in seconds (default: 10) | `60` | | `log-level` | No | Logging level (default: INFO) | `DEBUG` | **Supported database types:** `pg`, `mysql`, `kafka`, `opensearch`, `valkey`, `grafana` ## Troubleshooting **Pod not starting** ```bash kubectl -n exoscale-automation describe pod -l app=exo-dbaas-filter ``` - Verify secret exists: `kubectl -n exoscale-automation get secret exoscale-api-credentials` - Check ConfigMap values are correct **Authentication errors** - Verify API credentials are correct in the secret - Check IAM role has all required permissions (see Step 1) - Test credentials manually: `exo dbaas list` (after setting `EXOSCALE_API_KEY` and `EXOSCALE_API_SECRET`) **Database not updating** - Verify database name, zone, and type are correct in ConfigMap - Check logs for errors: Look for "Failed to update" messages **No IPs detected** - Verify cluster name and zone are correct in ConfigMap - Check SKS cluster has running nodes: `exo compute sks nodepool list my-cluster -z ZONE` **Enable debug logging:** Edit `deployment.yaml` ConfigMap: ```yaml log-level: "DEBUG" ``` Then reapply: ```bash kubectl apply -k . ``` ## Multiple Deployments Deploy multiple instances of this automation for different cluster-to-database pairings: **Example: Separate production and staging environments** The automation updates **all** configured databases with IPs from **all** configured clusters. For selective pairing (e.g., production cluster → production databases only), deploy separate instances in different namespaces: ```bash # Production environment (prod cluster → prod databases) kubectl create namespace exo-automation-prod kubectl -n exo-automation-prod create secret generic exoscale-api-credentials \ --from-literal=api-key='EXO...' \ --from-literal=api-secret='...' # Edit deployment.yaml ConfigMap: sks-clusters="prod-cluster:ch-gva-2", dbaas-services="prod-db:ch-gva-2:pg" kubectl apply -f deployment.yaml -n exo-automation-prod # Staging environment (staging cluster → staging databases) kubectl create namespace exo-automation-staging kubectl -n exo-automation-staging create secret generic exoscale-api-credentials \ --from-literal=api-key='EXO...' \ --from-literal=api-secret='...' # Edit deployment.yaml ConfigMap: sks-clusters="staging-cluster:de-fra-1", dbaas-services="staging-db:de-fra-1:pg" kubectl apply -f deployment.yaml -n exo-automation-staging ``` ## Cleanup To remove the automation: ```bash kubectl delete namespace exoscale-automation ``` To revoke the IAM credentials: ```bash exo iam api-key revoke dbaas-filter-key exo iam role delete dbaas-filter-role ``` ## Additional Resources - [GitHub Repository with Complete Source Code](https://github.com/exoscale-labs/sks-sample-manifests/tree/main/exo-k8s-dbaas-filter) - [Alternative Deployment Methods (Docker, VM)](https://github.com/exoscale-labs/sks-sample-manifests/tree/main/exo-k8s-dbaas-filter#quick-start) - [Pre-built Container Images](https://github.com/exoscale-labs/sks-sample-manifests/pkgs/container/dbaas-ip-filter) - [IAM Policy Reference](https://community.exoscale.com/reference/iam/index.md) --- url: https://community.exoscale.com/product/dbaas/how-to/terraform/ --- # Use Terraform for DBaaS You can use the [Terraform Exoscale Provider](https://registry.terraform.io/providers/exoscale/exoscale/latest/docs) to manage your DBaaS resources. ## Provider Configuration In the provider configuration, we define some variables that will be used later in the examples: ```hcl-terraform terraform { required_providers { exoscale = { source = "exoscale/exoscale" } } } provider "exoscale" { key = "${var.exoscale_api_key}" secret = "${var.exoscale_secret_key}" } variable "exoscale_api_key" { default = "api_key_value_here" } variable "exoscale_secret_key" { default = "api_secret_key_value_here" } variable "database_username" { default = "database_username_here" } variable "database_password" { default = "database_password_here" } # Customizable parameters locals { my_zone = "ch-gva-2" } ``` To manage the databases in multiple zones, you need to create [multiple provider configurations](https://www.terraform.io/language/providers/configuration#alias-multiple-provider-configurations), each with a different `alias`. For more information, you can check Terraform's [provider configuration](https://registry.terraform.io/providers/exoscale/exoscale/latest/docs) documentation. ## Manage Your Databases ### Create a PostgreSQL Database ```hcl-terraform resource "exoscale_dbaas" "postgres" { name = "databasename" plan = "hobbyist-2" type = "pg" zone = local.my_zone pg = { admin_username = "${var.database_username}" admin_password = "${var.database_password}" ip_filter = ["0.0.0.0/0"] version = "16" } } ``` You can find the nested options for [PostgreSQL here](https://registry.terraform.io/providers/exoscale/exoscale/latest/docs/resources/dbaas#nestedblock--pg) ### Create a Kafka Service ```hcl-terraform resource "exoscale_dbaas" "kafka" { name = "databasename" plan = "startup-2" type = "kafka" zone = local.my_zone kafka = { enable_cert_auth = true enable_kafka_connect = false enable_kafka_rest = false enable_sasl_auth = false enable_schema_registry = false ip_filter = ["0.0.0.0/0"] version = "3.8" } } ``` You can find the nested options specific for [Kafka here](https://registry.terraform.io/providers/exoscale/exoscale/latest/docs/resources/dbaas#nestedblock--kafka). ### Create a MySQL Database ```hcl-terraform resource "exoscale_dbaas" "mysql" { name = "databasename" plan = "startup-8" type = "mysql" zone = local.my_zone mysql = { admin_username = "${var.database_username}" admin_password = "${var.database_password}" ip_filter = ["0.0.0.0/0"] version = "8" } } ``` You can find the nested options specific for [MySQL here](https://registry.terraform.io/providers/exoscale/exoscale/latest/docs/resources/dbaas#nested-schema-for-mysql) ### Create a Valkey Instance ```hcl-terraform resource "exoscale_dbaas" "valkey" { name = "databasename" plan = "startup-8" type = "valkey" zone = local.my_zone valkey = { ip_filter = ["0.0.0.0/0"] } } ``` You can find the nested options specific for [Valkey here](https://registry.terraform.io/providers/exoscale/exoscale/latest/docs/resources/dbaas#nested-schema-for-valkey) ### Create a Grafana Instance ```hcl-terraform resource "exoscale_dbaas" "grafana" { name = "grafana" plan = "hobbyist-2" type = "grafana" zone = local.my_zone grafana = { ip_filter = ["0.0.0.0/0"] } } ``` You can find the nested options specific for [Grafana here](https://registry.terraform.io/providers/exoscale/exoscale/latest/docs/resources/dbaas#nested-schema-for-grafana) ### Create an OpenSearch Instance ```hcl-terraform resource "exoscale_dbaas" "opensearch" { name = "databasename" plan = "hobbyist-2" type = "opensearch" zone = local.my_zone opensearch = { ip_filter = ["0.0.0.0/0"] } } ``` You can find the nested options specific for [OpenSearch here](https://registry.terraform.io/providers/exoscale/exoscale/latest/docs/resources/dbaas#nested-schema-for-opensearch) ### Create a ClickHouse Service ClickHouse requires version 0.72.0 or later of the provider. ```hcl-terraform resource "exoscale_dbaas" "clickhouse" { name = "databasename" plan = "startup-16" type = "clickhouse" zone = local.my_zone clickhouse = { ip_filter = ["203.0.113.0/24"] } } ``` Manage the users of the service with the `exoscale_dbaas_clickhouse_user` resource. If you don't set a `password`, the API generates one: ```hcl-terraform resource "exoscale_dbaas_clickhouse_user" "analyst" { service = exoscale_dbaas.clickhouse.name zone = local.my_zone username = "analyst" } ``` You can find the nested options specific for [ClickHouse here](https://registry.terraform.io/providers/exoscale/exoscale/latest/docs/resources/dbaas#nestedatt--clickhouse), and the user options in the [`exoscale_dbaas_clickhouse_user` documentation](https://registry.terraform.io/providers/exoscale/exoscale/latest/docs/resources/dbaas_clickhouse_user). --- url: https://community.exoscale.com/product/dbaas/service-boundaries/ --- # Service Boundaries - DBaaS - [Limits and Quotas - DBaaS](https://community.exoscale.com/product/dbaas/service-boundaries/limits-and-quotas/index.md) - DBaaS Limitations and Quotas - [SLA - DBaaS](https://community.exoscale.com/product/dbaas/service-boundaries/sla/index.md) - DBaaS Service Level Agreement - [Pricing ↗︎](https://www.exoscale.com/pricing/#dbaas) --- url: https://community.exoscale.com/product/dbaas/service-boundaries/limits-and-quotas/ --- # Limits and Quotas - DBaaS ## Limits CLI/API/Portal Support : You can use the CLI and API to access the complete DBaaS features. The Portal has partial coverage now, but we are continually working to bring it full DBaaS functionality. Cross DBaaS Service Integration : Integration between DBaaS services is not currently possible. Multi-Zone Setup and Geo-Replication : All services that support replication from their protocol can be deployed with geo-redundancy from the CLI with the integration capabilities. Read more about this feature in the specifics of each service. However, forks are possible across zones, which enables you to start a copy of a service from one zone in another zone. Data Migration : Migrating from an existing non-Exoscale DBaaS is possible only from the Portal and applies to SQL-based services only. Service Plans Restrictions : Access to certain plans (e.g., Business, Premium) requires activation by the support team. Requests can be made during service creation. ## Quotas | Usage | Quota | | -------------------------------------------------------- | ------------------------ | | DBaaS services overall | 10 | ## Availability DBaaS is available in all zones. __Data Services__ | Service | Name | | --------------------- | -------------- | | Managed PostgreSQL | `pg` | | Managed MySQL | `mysql` | | Managed Kafka | `kafka` | | Managed OpenSearch | `opensearch` | | Managed Valkey | `valkey` | | Managed Grafana | `grafana` | | Managed Thanos | `thanos` | --- url: https://community.exoscale.com/product/dbaas/service-boundaries/sla/ --- # SLA - DBaaS ## DBaaS Service-Level Agreement (SLA) These product-specific SLAs define the Service Availability Target for Database as a Service (DBaaS). It applies to each Client using the Service. Capitalized terms used herein but not defined herein shall have the meanings set forth in the Exoscale Terms and Conditions or EUSA, whichever applies. Exoscale DBaaS is powered by managed-database technology from [Aiven Ltd.](https://aiven.io/) For transparency, this SLA reflects that foundation, but it is Exoscale's own commitment to the Client and applies to all paid DBaaS service plans. ### SLA | Plan | Metric | Target | Definition | | ------ | -------- | -------- | ------------ | | Startup | Availability | >= 99.95% | The Monthly Uptime Percentage during which Exoscale DBaaS is available and operational for use. Startup plans run on a single node, so availability is guaranteed at 99.95%. | | Business | Availability | >= 99.99% | The Monthly Uptime Percentage during which Exoscale DBaaS is available and operational for use. Business plans run on a multi-node, highly available setup, raising the guarantee to 99.99%. | | Premium | Availability | >= 99.99% | Same as Business: a multi-node, highly available deployment with a 99.99% Monthly Uptime Percentage guarantee. | | Hobbyist | Availability | Best effort, no formal SLA | No monetary credits or uptime guarantee apply. | ### Non-binding objectives | Plan | Metric | Target | Definition | | ------ | -------- | -------- | ------------ | | All | Backup success rate | >= 99% | A backup is successful when it is fully stored, listed, and restorable within the advertised retention window for the service plan. | #### Backup retention profile (per plan) For more information on how backups work and how to restore data, see the [Backups and Restore](https://community.exoscale.com/product/dbaas/how-to/backups-restore/index.md) guide. | Service type | Hobbyist | Startup | Business | Premium | | -------------- | ---------- | --------- | ---------- | --------- | | [Apache Kafka](https://community.exoscale.com/product/dbaas/service-specific/kafka/index.md) | No backups | No backups | No backups | No backups | | [ClickHouse](https://community.exoscale.com/product/dbaas/service-specific/clickhouse/index.md) | Plan not available | Daily backup up to 3 days | Daily backup up to 15 days | Daily backup up to 30 days | | [PostgreSQL](https://community.exoscale.com/product/dbaas/service-specific/postgreSQL/index.md) | 1 day with PITR | 2 days with PITR | 14 days with PITR | 30 days with PITR | | [MySQL](https://community.exoscale.com/product/dbaas/service-specific/mySQL/index.md) | 1 day with PITR | 2 days with PITR | 14 days with PITR | 30 days with PITR | | [OpenSearch](https://community.exoscale.com/product/dbaas/service-specific/opensearch/index.md) | Hourly backup for 1 hour and Daily backup for 1 day | Hourly backup for 24 hours and Daily backup for 3 days | Hourly backup for 24 hours and Daily backup for 14 days | Hourly backup for 24 hours and Daily backup for 30 days | | [Grafana](https://community.exoscale.com/product/dbaas/service-specific/grafana/index.md) | Backup every 1 hour up to 1 day | Backup every 1 hour up to 1 day | Plan not available | Plan not available | | [Valkey](https://community.exoscale.com/product/dbaas/service-specific/valkey/index.md) | Backup every 12 hours up to 1 day | Backup every 12 hours up to 1 day | Backup every 12 hours up to 3 days | Backup every 12 hours up to 3 days | | [Thanos](https://community.exoscale.com/product/dbaas/service-specific/thanos/index.md) | Plan not available | Data persisted in object storage (no snapshot backups) | Data persisted in object storage (no snapshot backups) | Plan not available | #### Nature of the Non-binding Objectives Commitment - This provision does not constitute a legally binding obligation but rather specifies a target value that Exoscale will endeavor to achieve. - In this case, no monetary credits or other compensation will be granted if the objective is missed. - This is provided for transparency and capacity-planning purposes only. ### Other product specifications For detailed product features, technical specifications, and tutorials, please refer to the [DBaaS documentation](https://community.exoscale.com/product/dbaas/index.md). ### Exclusions The following events are excluded from the Service Availability Target and shall not be considered a Service Outage, including but not limited to: - Caused by factors outside of Exoscale's reasonable control, including any force majeure event and hostile actions by third parties such as denial-of-service attacks. - Downtime caused by the use of Beta Services and/or Beta Features also called Preview. - Periodic [Maintenance Updates](https://community.exoscale.com/product/dbaas/how-to/maintenance-windows/index.md), which shall not occur more often than once (1) per calendar month. - Critical Bug fixes and Security Updates. - Customer-generated service system load (network requests, client queries, storage usage) that exceed the resource-based capabilities (network traffic, cpu usage, memory usage, disk usage) of the given service plan level. - Customer modification or termination of critical resources (including operating credentials, the VPC, virtual machines, object storage, networking) utilized by Provider to provide the Cloud Services. ### Client Responsibilities While Exoscale is responsible for operating and maintaining the DBaaS infrastructure, Client remains responsible for the following but not limited to: - Database schema design and query optimization - Backup strategy, restore validation, and disaster recovery planning - Monitoring of resource usage, performance, and costs - Application-level and network-level access control and credential management - Data classification and regulatory compliance for stored data - Client defined encryption and recovery keys - Set maintenance window time For a complete explanation of the shared responsibility framework between Exoscale and Clients, please see the [Exoscale Shared Responsibility Model documentation](https://community.exoscale.com/platform/compliance/shared-responsability-model/index.md). ### Retribution The standard retribution and SLA credit schemes apply for this product as described under [General Exoscale Terms and Conditions](https://www.exoscale.com/terms/) or [EUSA](https://www.exoscale.com/eusa/), whichever applies. The Service Credits shall be the sole remedy for not meeting the SLA. In the event that the Monthly Uptime Percentage for Exoscale DBaaS falls below the committed Service Level Objective, the Client will be eligible for service credits as follows: | Plan | Monthly Uptime Percentage | Service Credit Percentage of Monthly Service Fees for Affected Resources | | ------ | -------- | -------- | | Startup | from 99.95% to 98.3% | 50% | | Business and Premium | from 99.99% to 98.3% | 50% | | Any paid plan | below 98.3% | 100% | Service credits apply only to plans with a committed availability target (Startup, Business, and Premium); Hobbyist plans are best-effort. #### Claim Service Credit To request a service credit, refer to the Service Unavailability Credit section of the [Exoscale Terms and Conditions](https://www.exoscale.com/terms/) or the [EUSA](https://www.exoscale.com/eusa/), whichever applies. --- url: https://community.exoscale.com/product/dbaas/reference/ --- # Reference - DBaaS - [API DBaaS](https://community.exoscale.com/reference/api/dbaas/index.md) - All operations on DBaaS. (external) - [CLI DBaaS](https://community.exoscale.com/reference/cli/exo/dbaas/index.md) - All commands on DBaaS. (external) --- url: https://community.exoscale.com/product/dbaas/service-specific/ --- # Service-Specific - [PostgreSQL](https://community.exoscale.com/product/dbaas/service-specific/postgresql/index.md) - A powerful open-source relational database known for reliability, advanced SQL support, extensibility, and strong performance at any scale. - [MySQL](https://community.exoscale.com/product/dbaas/service-specific/mysql/index.md) - MySQL is a popular open-source relational database known for speed, reliability, ease of use, and broad support in web applications. - [Kafka](https://community.exoscale.com/product/dbaas/service-specific/kafka/index.md) - Apache Kafka is a distributed event streaming platform built for high-throughput, fault-tolerant, real-time data pipelines and messaging. - [OpenSearch](https://community.exoscale.com/product/dbaas/service-specific/opensearch/index.md) - OpenSearch is an open-source search and analytics engine for fast querying, full-text search, log analysis, and real-time insights at scale. - [Valkey](https://community.exoscale.com/product/dbaas/service-specific/valkey/index.md) - Valkey is an open-source, in-memory key-value store built for high performance, caching, message brokering, and real-time workloads. - [Grafana](https://community.exoscale.com/product/dbaas/service-specific/grafana/index.md) - Grafana is an open-source observability platform for dashboards, metrics, logs, and traces, enabling real-time monitoring and analysis. - [Thanos](https://community.exoscale.com/product/dbaas/service-specific/thanos/index.md) - Thanos extends Prometheus for long-term storage, global querying, and high availability, enabling scalable and resilient monitoring. - [ClickHouse](https://community.exoscale.com/product/dbaas/service-specific/clickhouse/index.md) - ClickHouse is an open-source, column-oriented database built for real-time analytics and sub-second queries on very large datasets.