Managed Databases on Kubernetes

MariaDB

Relational · GPLv2 · MySQL-compatible

Architecture

MariaDB separates SQL parsing, optimisation and execution from physical storage through a pluggable storage-engine API. The engine chosen for a table decides how its rows are stored, locked and recovered. InnoDB is the default and the only one most deployments need: rows live in a clustered B-tree ordered by primary key, so a primary-key lookup reaches the row directly, and secondary indexes store the primary key rather than a physical row pointer — which keeps them stable across page splits at the cost of a second traversal. Aria backs internal temporary tables, MyRocks is an LSM-tree engine for write-heavy, highly compressible data, and ColumnStore handles analytical scans. Mixing engines within a single transaction gives up the transactional guarantee, so in practice a schema picks one.

Because MariaDB keeps the MySQL wire protocol and dialect, existing MySQL clients, drivers and ORMs connect without modification. Compatibility is at the protocol and dialect level, not feature-for-feature — the two projects have diverged since the fork, and MariaDB-specific features have no MySQL equivalent.

Transactions and durability

InnoDB provides ACID semantics through a write-ahead redo log plus MVCC. A transaction is durable once its redo record is on disk; innodb_flush_log_at_trx_commit=1 forces that fsync at every commit, which is what makes durability real and also the single largest source of commit latency. Undo logs retain prior row versions so readers see a consistent snapshot without blocking writers, and the doublewrite buffer guards against torn pages when a write is interrupted mid-page. Locking is row-level, and the default isolation level is REPEATABLE READ.

The buffer pool is the setting that matters most for performance: it caches data and index pages, and it should be sized to the working set, not to the whole database. On Kubernetes it must also fit inside the pod's memory limit with headroom — a buffer pool sized against total node memory is the most common way to get a database OOM-killed.

Replication and high availability

Replication ships binary-log events from a primary to replicas. Asynchronous replication is the default and does not delay commits, which means a failover can lose transactions that had not yet reached a replica. Semi-synchronous replication makes the primary wait for at least one replica to acknowledge receipt, trading commit latency for a much smaller loss window. GTIDs make replicas repointable without hand-tracking log positions, which is what allows an operator to automate promotion. Galera is a different model again: certification-based synchronous replication across a quorum of nodes, where a transaction commits everywhere or nowhere.

Operating it here

The data directory sits on a single ReadWriteOnce volume — block storage, never a shared network filesystem. Backups are logical (mariadb-dump) or physical (mariabackup, which streams a consistent copy without stopping writes); we run both on a schedule and verify the restore rather than only the backup job's exit code.

# commit is durable only when the redo record reaches disk
innodb_flush_log_at_trx_commit = 1
sync_binlog                    = 1

# size to the working set, and inside the pod memory limit
innodb_buffer_pool_size        = 4G

Where it fits

MariaDB is the right default when the application already targets MySQL — WordPress, Magento, Odoo, most PHP applications, and the long tail of ERP and CRM systems — or when the workload is general-purpose OLTP with straightforward queries and a team whose runbooks are already MySQL runbooks. It is efficient on modest CPU and memory, which makes it the cheaper choice at small scale. It is the weaker choice when queries are analytically complex, when you need indexed document storage (its JSON type is validated text, not a binary indexed type), or when you want the extension ecosystem described below.

Redis

In-memory data structures · AGPLv3 / RSALv2

Architecture

Redis is a data structure server, not a key-blob cache. Values are typed — strings, hashes, lists, sets, sorted sets, streams, bitmaps, HyperLogLogs — and each type has native commands, so incrementing a counter, appending to a queue or updating a leaderboard is one server-side operation instead of a read-modify-write round trip with a race condition in the middle. Command execution is single-threaded on one event loop, which is why every command is atomic without any locking, and why one slow command (an unbounded KEYS, a large SORT) blocks every other client. I/O threads parallelise socket reads and writes, but not command execution.

Persistence and its limits

Two mechanisms, usable together. RDB writes a point-in-time snapshot by forking a child process; because the fork relies on copy-on-write, a write-heavy instance can transiently need substantially more memory than its dataset while the snapshot is written. AOF appends every write command to a log and replays it on restart, with appendfsync everysec as the usual compromise — bounded loss of about one second, without an fsync per command.

Memory management

The dataset lives in RAM, so memory is the capacity limit and the cost driver. maxmemory caps usage and an eviction policy decides what happens at the cap: allkeys-lru for a pure cache, volatile-ttl when only keys with an expiry may be discarded, and noeviction — which rejects writes rather than losing data — when Redis holds queues or sessions that must not silently vanish. Native per-key TTL is what makes Redis a correct cache rather than merely a fast one: expiry is enforced by the server, not by hopeful application logic.

# cache: discard the coldest keys under pressure
maxmemory        512mb
maxmemory-policy allkeys-lru

# queue/sessions: refuse writes rather than drop data
maxmemory-policy noeviction
appendonly       yes
appendfsync      everysec

Replication, failover and sharding

Replicas follow a primary asynchronously. Sentinel adds monitoring, quorum-based failure detection and automatic promotion for a single-primary deployment. Redis Cluster is the horizontal option: the keyspace is divided into 16,384 hash slots distributed across shards, each with its own replicas. Cluster mode constrains multi-key operations to keys that hash to the same slot, which is a schema decision — hash tags — made before deployment rather than after.

Where it fits

Redis belongs in front of a relational database, not instead of one. It is the right tool for sub-millisecond reads, session and token storage, caching of query results or rendered fragments, rate limiting and counters, job queues, Pub/Sub between services, and stream processing with consumer groups. It is the wrong tool whenever you need ad-hoc queries across keys, joins, or a durable transactional guarantee — it has no query language and no rollback, by design.

What we operate

The capabilities below apply to all three engines, and are the substance of the managed service. They are properties of the platform underneath the database, which is why they do not vary by engine.

High availability and failover

Clusters run multiple nodes with replication, spread across hosts by anti-affinity so no single failure takes a quorum. When a primary fails the operator detects it, promotes a replica, fences the demoted node to prevent split-brain, and repoints the read-write Service endpoint. Applications reconnect to the same DNS name; nothing in your connection string changes.

Backup, restore and recovery

Scheduled base backups and CSI volume snapshots are written through Velero to S3-compatible object storage held off the cluster, so a cluster-level failure does not take the backups with it. For PostgreSQL, continuous WAL archiving adds recovery to any chosen timestamp. We test restores rather than only monitoring that backup jobs exited zero — an unverified backup is a hypothesis, not a recovery plan.

Storage

Local NVMe for latency-bound data directories, Ceph RBD block for replicated and snapshot-capable volumes, and S3 object storage for backups and WAL archive. Volumes are dynamically provisioned and expand online without a maintenance window. Storage is €0.044/GB-month and backup €0.008/GB-month, with no per-GB egress charge.

Security and isolation

Credentials are held in Kubernetes Secrets and never in application images or manifests. Access to the database is over TLS, and NetworkPolicy restricts which pods can reach the database port at all — the default is that nothing can, until you say otherwise. RBAC governs who can act on the database resources, and the data sits on encrypted storage in the Netherlands under Dutch jurisdiction, with a standard DPA and no US Cloud Act exposure.

Monitoring and alerting

Per-engine exporters feed the cluster Prometheus, with Grafana dashboards covering connections, replication lag, cache hit ratio, lock waits, checkpoint activity and disk usage. Alerts are set on the conditions that precede an outage — replication lag trending up, a volume projected to fill, autovacuum falling behind — and route to our on-call engineers rather than to you.

Scaling

CPU and memory resize from the console, storage expands online, and read replicas can be added for query fan-out. Connection pooling keeps a large fleet of application pods from exhausting backend connections, which matters most for PostgreSQL. We apply the change and sequence the rollout; you do not plan it.

How it connects to the rest of the platform

A database here is a workload on the same cluster as everything else, so it inherits the platform rather than integrating with it across a boundary. It uses block and object storage through CSI for volumes, snapshots and backups; runs on the same compute as your containers, virtual machines and GPU nodes, so an AI workload queries its metadata store over the cluster network rather than the public internet; and uses cluster networking for internal Services and DNS, NetworkPolicy segmentation, load balancers and ingress where an external endpoint is needed, and Submariner for cross-cluster or site-to-site connectivity. All of it sits on managed Kubernetes.