Infrastructure Automation and CloudOps with the MariaDB SkySQL Terraform Provider


In today’s fast-paced world of cloud operations, managing complex cloud infrastructure can be a challenge. This challenge can become even more complicated when trying to manage resources that span across a number of different clouds and providers.  That’s why MariaDB has developed a new Terraform provider for MariaDB SkySQL, our cloud database service. The provider is designed to make database provisioning, security, and scaling easier than ever before. In this blog post, let’s explore how our Terraform provider simplifies the lives of CloudOps professionals. CloudOps teams can use this infrastructure automation to deliver tangible benefits for businesses through:

  • Infrastructure as Code
  • Database provisioning on any cloud
  • Resource deletion protection

What is a Terraform Provider?

HashiCorp Terraform Providers are plugins that enable Terraform to interact with various cloud platforms, services, and systems, allowing users to define and manage infrastructure resources in a declarative manner. They bridge the gap between the Terraform engine and the APIs of various services and cloud platforms so that users can define all of their infrastructure in a single, unified format.  By leveraging the concept of infrastructure as code, our provider brings the power of SkySQL into the Terraform ecosystem.

The Power of Infrastructure as Code – with examples

Here is an example of how you can provision a simple standalone SkySQL service located in Google Cloud using Terraform:

variable "topology" {
  type = string
  default = "es-single"

variable "name" {
  type = string
  default = "my-app-db"

variable "size" {
  type = string
  default = "sky-2x8"

variable "nodes" {
  type = number
  default = 1

data "skysql_versions" "default" {
  topology = var.topology

resource "skysql_service" "my-db" {
  service_type   = "transactional"
  topology       = var.topology
  cloud_provider = "gcp"
  region         = "us-central1"
  name           =
  architecture   = "amd64"
  nodes          = var.nodes 
  size           = var.size
  storage        = 100
  ssl_enabled    = true
  version        = data.skysql_versions.default.versions[0].name
  wait_for_creation = true

Using Terraform’s variable system, you can override the defaults set here and provision smaller single node topologies in your development environments, and then multi-node highly available setups, such as replicated transactions or Xpand topologies in our production environment. In addition, if you wish to perform a manual scaling, you can change this value in code from “sky-2×8” to “sky-4×16”. This change can then be tested and a record will be recorded in our code version control.

In addition to the above example, additional benefits you can take advantage of by using infrastructure as code include:

  • Portability: Infrastructure as code allows you to easily move your configuration between environments. In the SkySQL example, developers can reuse this code to spin up temporary resources to test changes and reproduce issues in an isolated environment, as well as manage persistent environments.
  • Auditing: Leverage version control systems such as Git. Every change is tracked and versioned, enabling a clear audit trail and making it simpler to detect and remediate issues. In the example, we demonstrated how manual scaling can be tracked in code version control.
  • Keeping resources in sync: Infrastructure as code ensures that your resources always match their specifications, reducing the risk of configuration drift and making it easier to maintain consistency across environments. This is particularly relevant when managing the SkySQL service with different topologies and sizes across various environments.
  • Fleet-wide changes in one place: Making changes to each piece of your infrastructure due to changing company policies and demands is easier when using Terraform modules that are all in a central location. A single change to one file, such as adding a new IP to an allowlist, can now update a setting across multiple databases and resources in many environments.
  • Align with CI/CD, Agile: Spinning up and down ephemeral environments to run automated test suites is a common CloudOps need. Also, setup and teardown of release pipeline infrastructure can save costs, depending on where your team is in the maturity curve of achieving continuous deployment versus continuous delivery, and/or the constraints of build length and frequency.

Multicloud Provisioning Made Easy

In modern cloud environments, you’ll often have the need to provision resources across multiple cloud and service providers.  Rather than using a different interface or API for each provider, terraform gives us a common method for not only provisioning multi-cloud resources, but tying those resources together for easy configuration.  The SkySQL terraform provider fits into this paradigm nicely to provide powerful, scaling databases that your applications running on other clouds can easily access.

Adding to the example above, the following snippet of code will allow you to pass database connection information and credentials directly to your applications running inside kubernetes:

data "skysql_service" "my-db" {
  service_id =

data "skysql_credentials" "my-db" {
  service_id =

resource "kubernetes_config_map" "database_config" {
  metadata {
    name = "database-config"

  data = {
    "database_host" =
    "database_port" =[0].ports[0].port

resource "kubernetes_secret" "database_credentials" {
  metadata {
    name = "database-credentials"

  data = {
    "username" =
    "password" =

Using this common terraform pattern, you can easily connect SkySQL to our applications running in cloud or on-prem kubernetes clusters.

Resource Deletion Protection

One of the standout features of our Terraform provider is resource deletion protection. This safeguards your infrastructure by preventing accidental or unauthorized deletions of critical resources. By incorporating this layer of protection, you can maintain the stability and reliability of your infrastructure while giving your team the confidence to make changes without fear of causing irreparable harm.  Simply add the following to your SkySQL service definition and you can prevent your production resources from accidental deletion while still allowing your developers to create and tear down temporary setups:

resource "skysql_service" "my-db" {
  . . .
  deletion_protection = var.enable_deletion_protection

Change Details and Confirmation

With our SkySQL Terraform provider, you can also see details about each change you’re considering – before it is executed. This lets engineers get confirmation about their changes via terraform plan, and ensure the changes you’re trying to make are correct.

Here is an example of a scale-up operation initiated by terraform. This looks good:

  # will be updated in-place
  ~ resource "skysql_service" "my-db" {
      + endpoint_service    = (known after apply)
        id                  = "dbdgf02807952"
        name                = "my-app-db"
      ~ size                = "sky-2x8" -> "sky-4x16"
        # (16 unchanged attributes hidden)

Hold on, wait!  Another operation that attempts to rename the database will destroy it first:

  # must be replaced
-/+ resource "skysql_service" "my-db" {
      ~ is_active           = true -> (known after apply)
      ~ name                = "production-db" -> "my-app-db" # forces replacement
        # (14 unchanged attributes hidden)


Our new Terraform provider offers a comprehensive solution for managing your hybrid cloud infrastructure with ease. By embracing the power of Infrastructure as Code, resource deletion protection, and change management, your company can streamline its cloud operations processes and achieve greater efficiency and agility.

Next Steps

Let’s get started automating your IT infrastructure with Terraform and MariaDB SkySQL: