MariaDB support · 24×7 Galera, MaxScale and InnoDB engineering for MariaDB 10.6 to 12.3 LTS, Community and Enterprise Server
MariaDB Support: 24×7 Galera, MaxScale and DBA Engineering
MinervaDB delivers enterprise MariaDB support for organisations running MariaDB where downtime and data loss are not acceptable. Principal engineers answer incidents around the clock, keep Galera Cluster certified and out of flow control, configure MaxScale for clean failover, tune InnoDB and the optimizer from evidence, prove mariadb-backup restores, and move estates off MariaDB 10.6 onto 11.8 or 12.3 LTS, on bare metal, Kubernetes and Amazon RDS for MariaDB.
What MariaDB support includes
One MariaDB DBA support team, from Galera to the optimizer
Our MariaDB support practice covers MariaDB Community Server and MariaDB Enterprise Server, standalone or clustered. Each area is handled by engineers who know where MariaDB diverged from MySQL, so advice fits the server you actually run.
24×7 incident response
Severity 1 answered in 15 minutes: lost Galera quorum, stuck SST, replication breaks, flow-control stalls, crashes and corruption.
Galera Cluster engineering
Topology and quorum design, certification-conflict reduction, gcache and flow-control sizing, safe bootstrap and rolling restarts.
MaxScale and replication
GTID replication, semi-sync, parallel appliers, readwritesplit routing, automatic failover and transaction replay.
Performance tuning
Slow-log and ANALYZE FORMAT=JSON evidence, index design, optimizer hints in 12.x, InnoDB and thread-pool tuning.
Upgrades and migrations
10.6 to 11.8 or 12.3 LTS, MySQL to MariaDB and back, Oracle to MariaDB with Oracle mode, each with a rollback path.
Backup, security, audit
mariadb-backup with binlog PITR drills, ed25519 and TLS, roles, data-at-rest encryption and the MariaDB Audit Plugin.
01 · Release series
MariaDB 10.6 has left community support: where to land next
MariaDB 10.6 reached community end of life on 6 July 2026. The supported LTS lines are now 10.11, 11.4, 11.8 and 12.3, which reached general availability in May 2026 and is supported by the community until June 2029. MariaDB 13.0 became a stable rolling release in September 2026, and 13.1 is a release candidate. Every MariaDB support engagement starts by placing each server on this table.
Figure 1. MariaDB support planning: release series as of October 2026 and the action we recommend for each. Source: MariaDB Foundation maintenance policy and release notes.
Which LTS should we move to from MariaDB 10.6?
12.3 LTS for new platforms that can absorb the snapshot-isolation default change, 11.8 or 11.4 where an application or connector needs more time. Note that 11.8 has a shorter community window (to June 2028) than 11.4 (to May 2029) and 12.3 (to June 2029), which matters if you plan to stay put for years.
What changes when we upgrade to MariaDB 12.3?
innodb_snapshot_isolation is ON by default, so REPEATABLE READ transactions that try to update rows changed after their snapshot fail with error 1020 instead of overwriting them. 12.3 also adds a full optimizer-hint syntax, caching_sha2_password for MySQL client compatibility, more Oracle-mode functions and buffered audit logging. We test each of these against your workload before cutover.
Should production run MariaDB 13.0?
Only where a specific feature such as UPDATE … RETURNING or InnoDB log archiving justifies quarterly upgrades. 13.0 is a rolling release, replaced each quarter, so most production estates are better served by an LTS series.
In-place upgrade 10.6 to 11.8 or 12.3 LTS, replicas first, with verification
# MariaDB support runbook: in-place upgrade 10.6 LTS -> 11.8 or 12.3 LTS. # Order: replicas first, primary last. One LTS hop at a time is the safest path. # Credentials come from ~/.my.cnf or an option file readable only by the DBA. # 1. Record where we start. mariadb -e "SELECT @@version, @@innodb_fast_shutdown, @@gtid_binlog_pos;" # 2. Slow shutdown flushes undo and the change buffer, so the new server # does not have to process old-format InnoDB structures at startup. mariadb -e "SET GLOBAL innodb_fast_shutdown = 0;" systemctl stop mariadb # 3. Replace packages (repository pinned to the target series), then start. # MariaDB 12.3 turns innodb_snapshot_isolation ON by default: REPEATABLE READ # transactions that update rows changed after their snapshot now fail with # error 1020 instead of silently overwriting. Test the application for it. systemctl start mariadb # 4. Upgrade the system tables and check every table for incompatibilities. mariadb-upgrade # 5. Verify: version, replication health, and any table mariadb-upgrade flagged. mariadb -e "SELECT @@version; SHOW REPLICA STATUS\G" | grep -E "version|Running|Seconds_Behind"
02 · MariaDB and MySQL
Why MariaDB support needs MariaDB specialists, not MySQL generalists
MariaDB and MySQL share a wire protocol and a history, but they have diverged for more than a decade. GTIDs are formatted differently, JSON is stored differently, authentication plugins differ, and the optimizers make different choices. Treating MariaDB as a MySQL clone is the most common root cause we meet when we take over an estate.
Figure 2. Where MariaDB and MySQL diverge in 2026, as seen from MariaDB support, and what each difference means for support and migrations.
Can a MySQL replica replicate from MariaDB, or the reverse?
Not with GTIDs, because the formats are incompatible. Position-based replication works in limited version combinations, so migrations between the two normally use logical dump and load with a short cutover, or change data capture, and we test every direction before relying on it.
Do you migrate MySQL to MariaDB?
Yes, and MariaDB to MySQL. We inventory JSON columns, authentication plugins, SQL modes, reserved words and engine-specific features first, then rehearse the move on a copy with plan comparisons for the top statements.
Do you also support MySQL?
Yes. Our MySQL support practice covers Oracle MySQL 8.4 and 9.7, and we advise honestly on which of the two servers fits a workload better.
03 · Galera Cluster internals
MariaDB support for Galera: certification, conflicts and flow control
Galera is built into MariaDB Server as open source. It replicates at commit: the writeset is ordered across the cluster and certified on every node with the same deterministic test. That design gives synchronous, multi-primary replication without a coordinator, and it explains the three issues our MariaDB DBA support team handles most often: certification conflicts on hot rows, flow control caused by one slow node, and state transfers that block a donor.
Figure 3. The Galera commit path our MariaDB DBA support team works with daily. A conflict is detected at certification and surfaces to the client as a deadlock error.
MariaDB support configuration for a Galera node, with the reason for each setting
# /etc/mysql/mariadb.conf.d/60-galera.cnf -- MariaDB support baseline, 3-node Galera
# Paths are Debian/Ubuntu defaults; RHEL uses /usr/lib64/galera-4/libgalera_smm.so
[galera]
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = prod-galera
wsrep_cluster_address = gcomm://10.0.2.11,10.0.2.12,10.0.2.13
wsrep_node_address = 10.0.2.11
wsrep_sst_method = mariabackup # non-blocking state transfer for new nodes
wsrep_sst_auth = sst_user:${GALERA_SST_PASSWORD} # rendered from the secret store
wsrep_slave_threads = 8 # parallel appliers; size to CPU and write rate
wsrep_provider_options = "gcache.size=4G; gcs.fc_limit=256; gcs.fc_factor=0.9"
binlog_format = ROW # required by Galera
innodb_autoinc_lock_mode = 2 # interleaved auto-increment, required by Galera
Galera health check, run on every node
-- MariaDB DBA support check: Galera health in one query, run on each node. SELECT variable_name, variable_value FROM information_schema.global_status WHERE variable_name IN ( 'WSREP_CLUSTER_STATUS', -- must be Primary; Non-Primary means lost quorum 'WSREP_CLUSTER_SIZE', -- expected node count 'WSREP_LOCAL_STATE_COMMENT', -- Synced is healthy; Donor/Joiner during SST/IST 'WSREP_READY', -- ON when the node accepts queries 'WSREP_FLOW_CONTROL_PAUSED', -- fraction of time paused by flow control 'WSREP_LOCAL_RECV_QUEUE_AVG', -- above ~1 means this node applies too slowly 'WSREP_LOCAL_CERT_FAILURES', -- certification conflicts since startup 'WSREP_LOCAL_BF_ABORTS' -- local transactions aborted by replicated ones );
Why do we see deadlock errors with Galera?
Two nodes changed the same rows at nearly the same time; the writeset certified second is aborted and the client receives error 1213. The fix is to send writes for a given set of rows to one node, usually through MaxScale or a single-writer routing rule, and to make the application retry deadlocks.
How many Galera nodes do we need?
At least three, or two plus a Galera Arbitrator (garbd), so a single failure or network split leaves a majority with quorum. Across two data centres we add a third site for the arbitrator, otherwise losing either site can stop the cluster.
What causes flow control?
A node whose receive queue exceeds gcs.fc_limit asks the cluster to pause. Typical causes are slow disks, too few applier threads, very large transactions and a node acting as SST donor. We size each and alert on wsrep_flow_control_paused before users notice.
Can Galera clusters replicate to each other?
Yes, using asynchronous replication between clusters, and MariaDB 12.3 allows parallel replication between Galera clusters with slave_parallel_threads. We use it for cross-region disaster recovery where synchronous replication would add too much latency.
04 · Replication and MaxScale
MariaDB support for primary-replica topologies with tested automatic failover
For many workloads, asynchronous or semi-synchronous GTID replication behind MariaDB MaxScale is simpler and faster than a Galera cluster. MaxScale gives applications one endpoint, splits reads from writes, promotes the most current replica when the primary fails and can replay an interrupted transaction. MaxScale is released under the Business Source License, so we confirm production-use terms with each client.
Figure 4. A MariaDB support reference design: MaxScale in front of a GTID replication topology: one endpoint, routed traffic, automatic failover.
MaxScale read/write split with automatic failover and transaction replay
# /etc/maxscale.cnf -- MariaDB support reference: read/write split with automatic failover.
# Passwords are encrypted with maxpasswd and injected at deploy time; never plain text.
[maxscale]
threads = auto
[db1]
type = server
address = 10.0.3.11
port = 3306
[db2]
type = server
address = 10.0.3.12
port = 3306
[db3]
type = server
address = 10.0.3.13
port = 3306
[Replication-Monitor]
type = monitor
module = mariadbmon
servers = db1, db2, db3
user = maxscale_monitor
password = ${MAXSCALE_MONITOR_PASSWORD_ENCRYPTED}
monitor_interval = 2s
auto_failover = true # promote the most up-to-date replica if the primary dies
auto_rejoin = true # old primary rejoins as a replica when it returns
enforce_read_only_slaves = true
[RW-Split-Service]
type = service
router = readwritesplit
servers = db1, db2, db3
user = maxscale_service
password = ${MAXSCALE_SERVICE_PASSWORD_ENCRYPTED}
transaction_replay = true # replays an interrupted transaction on the new primary
causal_reads = local # a session reads its own writes from replicas
[RW-Split-Listener]
type = listener
service = RW-Split-Service
port = 4006
GTID replication with strict mode and optimistic parallel apply
-- MariaDB DBA support: GTID replication setup and health on a replica.
-- MariaDB GTIDs are domain-server-sequence, e.g. 0-11-48211, not MySQL UUID GTIDs.
SET GLOBAL gtid_strict_mode = ON; -- refuse out-of-order or duplicate GTIDs
SET GLOBAL slave_parallel_mode = 'optimistic'; -- apply in parallel, roll back on conflict
SET GLOBAL slave_parallel_threads = 8; -- requires the replica threads to be stopped
CHANGE MASTER TO
MASTER_HOST = '10.0.3.11',
MASTER_USER = 'repl',
MASTER_PASSWORD = '${REPL_PASSWORD}', -- rendered from the secret store
MASTER_SSL = 1,
MASTER_USE_GTID = slave_pos; -- resume from the replica's own GTID position
START REPLICA;
-- Health: both threads running, lag, and positions on each side.
SHOW REPLICA STATUS\G
SELECT @@gtid_slave_pos AS replica_pos, @@gtid_binlog_pos AS own_binlog_pos;
| Topology | Data loss on failover | Best for |
|---|---|---|
| Async GTID + MaxScale | seconds of lag possible | read scaling, simple operations |
| Semi-sync + MaxScale | near zero | OLTP with a single writer |
| Galera, 3 nodes | zero within the cluster | synchronous HA in one region |
| Galera + async DR cluster | lag of the DR link | cross-region disaster recovery |
05 · Performance engineering
MariaDB tuning from the slow log, ANALYZE and InnoDB metrics
MariaDB ships with performance_schema disabled by default, so our MariaDB support work usually starts from the slow query log with plan output, then proves each cause with ANALYZE FORMAT=JSON, which runs the statement and shows actual row counts beside the estimates. Since MariaDB 11.0 the optimizer uses a rewritten cost model, and 12.x adds the full optimizer-hint syntax, so plans are re-baselined after every major upgrade.
MariaDB support diagnostics: slow log, ANALYZE, live EXPLAIN and purge backlog
-- MariaDB support diagnostics. performance_schema is OFF by default in MariaDB,
-- so the slow query log with plan output is usually the first evidence source.
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 0.5; -- seconds
SET GLOBAL log_slow_verbosity = 'query_plan,explain'; -- plan and EXPLAIN in the log
-- Prove the cause on one statement. ANALYZE executes it and reports actual rows
-- (r_rows) and filtering (r_filtered) next to the optimizer's estimates.
ANALYZE FORMAT=JSON
SELECT customer_id, SUM(amount)
FROM orders
WHERE created_at >= NOW() - INTERVAL 1 DAY
GROUP BY customer_id;
-- Live plan of a statement that is already running in another session.
SHOW EXPLAIN FOR 4711; -- connection id from PROCESSLIST
-- Long transactions pin undo history and grow the purge backlog.
SELECT trx_mysql_thread_id, trx_started, trx_rows_modified,
TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS age_s
FROM information_schema.innodb_trx
ORDER BY trx_started
LIMIT 10;
SHOW GLOBAL STATUS LIKE 'Innodb_history_list_length';
Server baseline for 11.8 and 12.3: default, reason and reload behaviour per line
# /etc/mysql/mariadb.conf.d/50-minervadb.cnf -- MariaDB support baseline, MariaDB 11.8 / 12.3, 64 GB host (illustrative) # Format: parameter = proposed # default -> why ; dynamic or restart [mariadbd] innodb_buffer_pool_size = 44G # 128M -> ~70% of RAM for the working set ; dynamic innodb_log_file_size = 8G # 96M -> fewer checkpoint stalls under bursts ; dynamic since 10.11 innodb_flush_log_at_trx_commit = 1 # 1 -> keep: full durability ; dynamic sync_binlog = 1 # 0 -> binlog survives a crash, safe for replicas ; dynamic innodb_io_capacity = 4000 # 200 -> match sustained IOPS of the volume ; dynamic binlog_format = ROW # MIXED -> deterministic replication and CDC ; dynamic log_slave_updates = ON # replicas keep binlogs for promotion ; restart gtid_strict_mode = ON # OFF -> catch divergent writes early ; dynamic thread_handling = pool-of-threads # one-thread-per-connection -> stable under spikes ; restart max_connections = 800 # 151 -> sized to pooler output, not app instances ; dynamic performance_schema = ON # OFF -> wait and statement evidence ; restart
Should we use the thread pool?
Usually yes on busy servers. thread_handling=pool-of-threads is part of MariaDB Community Server and keeps throughput stable when connection counts spike, where one thread per connection would thrash. It needs a restart, so we enable it on a replica first.
When do optimizer hints help?
When a plan regression is proven and a statistics or index fix is not possible quickly. MariaDB 12.x hints such as JOIN_ORDER, NO_RANGE_OPTIMIZATION and MAX_EXECUTION_TIME pin a plan per statement; we record each hint and remove it once the root cause is fixed.
What does r_filtered show?
The percentage of rows that passed the WHERE condition at that step, measured during ANALYZE. A low value on a large table means the access method reads far more rows than it returns, which usually points to a missing or unusable index.
06 · Backup and recovery
MariaDB support counts a backup only after a restore drill
We combine mariadb-backup physical backups with binary-log point-in-time recovery, and we restore them on separate hosts on a schedule. RPO and RTO become numbers measured in the last drill. MariaDB 13.0 adds InnoDB log archiving, which we evaluate as an extra recovery layer where it fits.
MariaDB support restore drill: mariadb-backup plus binlog PITR, with guards and validation
# MariaDB support restore drill: mariadb-backup plus binlog point-in-time recovery,
# on a separate drill host. Every guard below must pass before anything is written.
set -euo pipefail
BK=/backups/full-2026-10-05 # prepared full backup copied to the drill host
DRILL=/srv/restore-drill/data
STOP="2026-10-05 09:30:00" # recovery target
# Guard 1: never the live datadir, never a running server.
case "$DRILL" in /var/lib/mysql*) echo "refusing: production datadir"; exit 1;; esac
if pgrep -f "datadir=$DRILL" >/dev/null; then echo "refusing: server running"; exit 1; fi
# Verification before: the backup is complete and records its binlog position.
grep -q "completed OK" "$BK"/backup.log && cat "$BK"/*binlog_info
# Guard 2: typed confirmation, because the drill directory is emptied.
read -r -p "Type RESTORE-DRILL to wipe $DRILL: " ok
[ "$ok" = "RESTORE-DRILL" ] || { echo "aborted"; exit 1; }
rm -rf "${DRILL:?}"/* && mkdir -p "$DRILL"
mariadb-backup --prepare --target-dir="$BK"
mariadb-backup --copy-back --target-dir="$BK" --datadir="$DRILL"
chown -R mysql:mysql "$DRILL"
mariadbd --user=mysql --datadir="$DRILL" --port=3399 --socket=/tmp/drill.sock \
--skip-slave-start --skip-log-bin &
# Replay binlogs from the recorded position up to the target time.
# (start position taken from the *_binlog_info file shown above)
mariadb-binlog --start-position=4211 --stop-datetime="$STOP" /binlogs/mariadb-bin.000731 \
| mariadb --socket=/tmp/drill.sock
# Validation after: newest business row sits just before the target.
mariadb --socket=/tmp/drill.sock -e "SELECT MAX(created_at), COUNT(*) FROM app.orders;"
| Method | Best for | Restore speed | PITR |
|---|---|---|---|
| mariadb-backup | large self-managed servers, Galera SST | fast, physical | with binlogs |
| mariadb-dump | small schemas, migrations | slow, logical | with binlogs |
| Storage snapshots | cloud volumes, RDS for MariaDB | fast | provider window |
| Delayed replica | fast recovery from human error | immediate | within the delay |
Can we back up a Galera node without hurting the cluster?
Yes. mariadb-backup takes a non-blocking copy of InnoDB data; we run it on a node excluded from application traffic and watch flow control while it runs, since backup I/O can slow that node’s appliers.
What do you check after a restore?
The newest business row against the recovery target, row counts and checksums on critical tables, application smoke tests and the elapsed time, which becomes the measured RTO.
07 · Security and compliance
MariaDB controls that hold up in an audit
Enterprise MariaDB support covers the controls auditors ask for and the evidence that proves them: ed25519 or socket authentication, TLS on every connection, role-based privileges, data-at-rest encryption with key rotation, and audit trails routed to your SIEM.
Enterprise MariaDB support baseline: ed25519 accounts, roles, the audit plugin and a privilege review
-- Enterprise MariaDB support hardening baseline (MariaDB 10.4+ syntax).
-- 1. Strong authentication: ed25519 or unix_socket, never mysql_native_password.
CREATE USER 'svc_orders'@'10.20.%'
IDENTIFIED VIA ed25519 USING PASSWORD('${SVC_ORDERS_PASSWORD}')
REQUIRE SSL;
-- 2. Roles carry privileges; accounts only receive roles.
CREATE ROLE app_write;
GRANT SELECT, INSERT, UPDATE, DELETE ON app.* TO app_write;
GRANT app_write TO 'svc_orders'@'10.20.%';
SET DEFAULT ROLE app_write FOR 'svc_orders'@'10.20.%';
-- 3. Audit trail with the MariaDB Audit Plugin, buffered writes in 12.3.
INSTALL SONAME 'server_audit';
SET GLOBAL server_audit_events = 'CONNECT,QUERY_DDL,QUERY_DCL';
SET GLOBAL server_audit_logging = ON;
-- 4. Review: weak plugins, accounts open to any host, and global SUPER-style rights.
SELECT user, host, plugin FROM mysql.user
WHERE plugin IN ('mysql_native_password', 'mysql_old_password') OR host = '%';
SELECT grantee, privilege_type FROM information_schema.user_privileges
WHERE privilege_type IN ('SUPER', 'SHUTDOWN', 'FILE');
Is TLS enabled by default in MariaDB?
From MariaDB 11.4, the server enables TLS with automatically generated certificates when none are configured, and clients verify them. We replace those with certificates from your PKI and enforce REQUIRE SSL for application accounts.
Do you configure data-at-rest encryption?
Yes: InnoDB and Aria tablespace, redo log and binlog encryption through file_key_management (sha256 key files from 12.3) or a key management service, with rotation procedures and restore tests so encrypted backups stay usable.
Which compliance regimes do you support?
We map MariaDB controls to SOC 2, PCI DSS, HIPAA, GDPR and India’s DPDP Act, and produce configuration evidence, access reviews and audit samples for assessors.
08 · Engines, editions and cloud
MariaDB support beyond InnoDB: engines, Enterprise Server and managed services
MariaDB is more than InnoDB, and each engine or edition changes how we operate it. Our MariaDB support covers the parts of the server that MySQL does not have, and the managed services where MariaDB runs today.
Vector search
VECTOR columns and HNSW-based vector indexes since 11.7, available in the 11.8 and 12.3 LTS lines, for retrieval workloads next to transactional data.
Aria and MyRocks
Crash-safe Aria for internal temporary tables, MyRocks for write-heavy, compression-sensitive datasets on flash storage.
ColumnStore and Spider
Columnar analytics inside MariaDB, and Spider for sharding across servers, each with its own backup and upgrade rules.
Oracle mode
sql_mode=ORACLE with PL/SQL syntax, packages, associative arrays and SYS_REFCURSOR in 12.3, for Oracle-to-MariaDB moves.
| Platform | What differs | What we engineer |
|---|---|---|
| MariaDB Community Server | open source, community LTS windows, Galera built in | full lifecycle support, upgrades, HA and tuning |
| MariaDB Enterprise Server | longer enterprise support windows, enterprise-only features and tooling | operations alongside your vendor subscription, feature-fit reviews |
| Amazon RDS for MariaDB | no SUPER, parameter groups, provider maintenance and version calendar | parameter baselines, Multi-AZ tests, replica design, upgrades |
| Azure Database for MariaDB | retired by Microsoft on 19 September 2025 | migration to self-managed MariaDB or another supported service |
| Kubernetes | operators, storage classes, pod disruption | MariaDB operator and Galera on Kubernetes with tested backups |
09 · 24×7 operations
How our MariaDB DBA support runs, and the response times we commit to
Principal engineers hold your runbooks, monitoring access and topology map before the first incident. Response targets are commitments for an engineer to be actively working the problem, not for an automated acknowledgement.
S1 · 15 minutes
Production down or data at risk: lost quorum, crashed primary, broken replication on the critical path.
S2 · 12 hours
Severe degradation with a workaround: flow-control stalls, lag beyond the RPO, failing backups.
S3 · 24 hours
Non-critical defects, configuration questions and planned changes needing review.
S4 · 48 hours
Advice, capacity planning, version roadmaps and architecture questions.
Onboarding
Access, topology, baselines, Galera and replication review, backup verification and a ranked risk register in the first weeks.
Monthly reviews
Growth, slow-query trends, certification failures, lag, backup drills, security drift and the release calendar.
Knowledge transfer
Runbooks, RCAs and alert rules stay with your team, so support builds capability instead of dependency.
FAQ
MariaDB support questions we hear before a contract
Short answers for CTOs, platform leads and DBA managers comparing enterprise MariaDB support options.
What is included in MinervaDB MariaDB support?
24×7 incident response, Galera Cluster and MaxScale engineering, replication, performance tuning, mariadb-backup restore drills, upgrades and migrations, security hardening and monthly proactive reviews, for Community and Enterprise Server.
How fast do you respond to a MariaDB outage?
Severity 1 incidents get a named engineer working the problem within 15 minutes, 24×7×365. Severity 2 is 12 hours, Severity 3 is 24 hours and Severity 4 is 48 hours.
How does MariaDB support differ from remote DBA?
Support centres on incidents and expert escalation; remote DBA adds routine operations such as patching, user administration and capacity work. Many clients combine both through our MariaDB remote DBA service.
Do you work alongside a MariaDB plc subscription?
Yes. We handle architecture, tuning, operations and incident response day to day, and work with your vendor support for product defects and enterprise-only features.
Can you take over during a live incident?
Yes. Emergency engagements start with read-only access and evidence capture, then mitigation; formal onboarding follows once service is stable.
Are you tied to MariaDB or any vendor?
No. MinervaDB is vendor-neutral and sells no licences, so recommendations, including staying on MySQL or moving to PostgreSQL when that fits better, rest only on your workload. That independence is the core of our MariaDB support.
Guidance on this page is general and pinned to the MariaDB versions named. Test every configuration change, upgrade, failover and restore step in a non-production environment first, verify backups by restoring them, and maintain a robust disaster-recovery posture. Related services: MariaDB consulting · MariaDB remote DBA · MySQL support · Amazon RDS support · 24×7 emergency DBA coverage · MariaDB maintenance policy · MariaDB Community Server release notes
Need MariaDB support you can call at 3 a.m.?
Talk to a MariaDB principal engineer about your Galera cluster, your SLAs and your move off 10.6. contact@minervadb.com · +1 (844) 588-7287.