Skip to content

MariaDB databases

On GRN.CLOUD, every project runs its own MariaDB server, inside its own namespace, on storage the project owns. It is the same model as PostgreSQL: not a managed service in which you rent a slice of a shared server. This page explains how the pieces fit, because the consequences show up in how you create and delete things.

Why there is no shared server

A shared server is cheaper to run. It also means the provider holds root, the storage and the backups, and "your database" is a logical boundary inside someone else's system, enforced by configuration.

So there is no shared server here. Instead:

  • Each project creates its own MariaDB (k8s.mariadb.com/v1alpha1) when it needs one.
  • The server runs in your namespace, on your persistent volume.
  • The operator reconciles it; it does not own it. Delete the project and the data goes with it, because there is nowhere else it lives.

The cost is one MariaDB server's worth of resources per project rather than a shared pool. That is the trade being made deliberately: capacity efficiency given up for a boundary that is structural rather than configured.

Server and Database are different objects

flowchart TB
    subgraph P["your project - your namespace, your storage"]
        direction TB
        SRV["MariaDB<br/>the server: pod, PVC, root Secret"]
        DB1["Database: orders"]
        DB2["Database: billing"]
        U1["User: orders-user<br/>Grant: all on orders"]
        U2["User: billing-user<br/>Grant: all on billing"]
        SVC["Service"]
        SRV --> DB1
        SRV --> DB2
        DB1 --- U1
        DB2 --- U2
        SRV --- SVC
    end
    APP["your workload"] -->|credentials from its Secret| U1
    APP -->|connects| SVC

A MariaDB is the running server: one pod, one volume, a root password in a Secret you never hand to an application. You need a minimum of one, and one is enough for many databases.

A Database is a request against that server. It comes with a User, the login your application connects as, and a Grant that gives that user all privileges on that one database and nothing else. All three reference the server by name with waitForIt, so they wait for it to be ready rather than failing while it starts.

If no server exists when you create a database

The console form offers the servers in your project and a Create new ... entry, selected already when the project has none. Saving then creates the server first and the database against it, in one go.

On the command line the order is yours

Two Templates do the work, mariadb-instance and mariadb-database. Run the first once per project, then the second per database. The database objects reference the server with waitForIt, so they wait for it to be ready rather than failing while it starts.

Root once per server, one user per database

Created Can Use it for
root once, with the server everything administering the server
Database user with each database log in and use its own database your application

Root's password lands in a Secret named <server>-root. The console does not offer it as a field, because no application should hold it.

Each database user gets a Secret named <database>-db-user carrying username, password, host, port and database: everything a workload needs to connect, so point it at the Secret rather than copying values into a manifest. Two applications on the same server cannot reach each other's data by holding the wrong credential.

What is fixed after creation

Changeable
Server storage size yes, it can be grown but never shrunk
Database name no, create a new one and move the data
Which server it lives on no
Character set and collation no, fixed at utf8mb4 and utf8mb4_unicode_ci by the template

Deleting the object does not drop the database

The Database object is created with cleanupPolicy: Skip, so deleting it leaves the database and its contents on the server, still occupying storage and still holding the name. That is deliberate: an accidental oc delete should not destroy a database. See Delete for how to drop it when you mean to.

Deleting the MariaDB server is the opposite: it removes every database on it.

oc get databases is ambiguous

PostgreSQL installs a Database kind too, so in a project running both the short form returns whichever the API server resolves first. Use databases.k8s.mariadb.com.

In a subnet, the server is reachable but not backed up

A project that is a subnet has a network of its own. The server runs inside it, so workloads in the same subnet connect to it as usual. The template configures no backups for any server, in a subnet or not; take dumps of data you need back. See Delete.