Skip to content

All about databases

A database in Core is a MariaDB or PostgreSQL database hosted on the cluster. This article walks through creating one and the optimisation and backup toggles, which behave differently per server software.


Where to find databases

In Core, the top-level 'Databases' page lists databases across your clusters. Click 'Create' to add one.

Creating a database

Required fields

  • 'Cluster' — which cluster the database lives on. Clusters without database support are disabled in the dropdown.
  • 'Name' — lowercase, digits, dash, underscore. Max 63 characters.
  • 'Server Software' — pick 'MariaDB' or 'PostgreSQL'. Tiles are disabled if the cluster doesn't support that software.

Auto-create user and grant (MariaDB only)

Toggle 'Create user and grant' on to also create a database user with full privileges on the new database — saving the separate user and grant steps. You'll be asked for a 'User password' (minimum 24 characters).

This shortcut isn't available for PostgreSQL.

Advanced options

Two more toggles live under 'Show advanced options':

  • 'Optimising' — runs OPTIMIZE TABLE on the database on a weekly schedule. MariaDB only. This defragments each table: as rows are deleted and updated over time, the table file on disk develops gaps where the freed slots aren't reused. OPTIMIZE TABLE rebuilds each table from scratch, copying the live rows into a fresh, densely packed file. The result is a smaller file on disk and faster table scans (the engine reads fewer pages because the rows are back to back).
  • 'Backups' — daily automatic backups. On by default. Can only be disabled for MariaDB databases.

Server-software differences

The optimising, backups, and auto-create toggles all behave differently per server software:

  • MariaDB — optimising can be enabled, backups can be turned off, auto-create user is supported.
  • PostgreSQL — optimising is not supported, backups are always on (the toggle is locked), auto-create is not supported.

The Create page reflects these constraints automatically: when you select PostgreSQL, the unavailable toggles grey out.

Backups: which kind?

The 'Backups' toggle here is the local-on-master daily backup rotation — the one Cyberfusion uses for fast restore. For long-term retention, set up a Borg repository pointed at the database. See All about backups for the difference between the two.

Usage tracking

The cluster periodically measures each database's on-disk size and reports it back to Core. The size is what the management interface shows on the database row, and what billing-style usage reports use. No configuration required.

MariaDB encryption

Cyberfusion offers 'MariaDB encryption keys' — a cluster-level feature that encrypts MariaDB data at rest (the database files on disk).

What changes for you

Nothing changes in how you interact with the data:

  • Queries, dumps (mysqldump), and restores work exactly as before.
  • phpMyAdmin and any other client sees the same content as before.
  • Backups read out the same content.

Encryption only applies to how the data sits on disk. As soon as MariaDB reads a row to serve a query, it's decrypted in memory.

Performance overhead

In steady state, expect roughly 3–5% lower throughput. For most workloads this is unnoticeable; for very read-heavy or write-heavy databases on shared clusters, measure it on a representative workload before enabling it on a busy production database.

Turning it on

When you enable 'MariaDB encryption keys', MariaDB immediately starts encrypting all existing data on disk — table by table, in the background. While that initial pass is running:

  • Cluster load is higher than usual.
  • Per-query latency may be slightly elevated.
  • Other tenants on the same cluster may also see slower queries.

How long the initial encryption takes depends on how much data is on disk: a small database finishes in minutes; a multi-hundred-GB database can take hours.

Plan to enable it during a quieter period if you have one.

MariaDB character set: utf8mb3 and .NET clients

MariaDB exposes two related sets — utf8mb3 and utf8mb4 — and the encoding hasn't changed in years; only the name the server reports back to clients has. Older MariaDB versions returned this set as utf8. Current versions return the explicit utf8mb3.

Most clients accept either spelling. The notable exception is MySQL Connector/NET, used by PowerBI and other .NET tools. Old Connector/NET versions don't recognise the utf8mb3 name and fail with:

The error

Character set 'utf8mb3' is not supported by .Net Framework

The character set itself is unchanged from what these clients were happily talking to before — only the name is.

Update the Connector. MySQL Connector/NET added support for the utf8mb3 name on 17 November 2021. If you're hitting this error now, the client install is on a very old Connector.

Avoid Connector/NET 9.7.0

Version 9.7.0 has unrelated bugs we've seen break PowerBI connections. Use 9.3 instead — a known-good newer version. Downgrading from 9.7.0 to 9.3 has resolved the issue in customer cases.