MySQL eller MariaDB för din egen databasserver

Det korta svaret

Välj MariaDB för WordPress och de flesta PHP-appar, och när appen bara skriver "MySQL eller MariaDB". I vårt test skrev den snabbare, återställde en dump på halva tiden, har sitt verktyg för fysiska säkerhetskopior i samma avbild, och har en ideell stiftelse vid sidan av företaget bakom den.

Välj MySQL när appen kräver "MySQL 8 eller nyare" och menar det: den använder SQL som bara MySQL förstår, som ->> på JSON-kolumner, eller behöver Group Replication, InnoDB Cluster eller MySQL:s dokumentlager. MySQL läste något snabbare, startade med mindre minne, och dess JSON är en riktig binär typ.

Det här testade vi

Båda kördes på samma VC-P Alloy (2 vCPU, 8 GB) hos Melonslab med Debian 13, uppsatta precis som i våra guider: MySQL under användaren mysql, och MariaDB under användaren mariadb, var och en som en enda container i Podman utan root, med den officiella avbilden. Båda guiderna har samma minnesinställningar: 4 GB buffertpool för InnoDB, 1 GB redo-logg, 200 anslutningar och 64 MB för tillfälliga tabeller.

Båda guiderna använder port 3306, så i det här testet lyssnade MySQL på 3307: en rad, port = 3307, i dess server.cnf, och -P 3307 i hälsokontrollen. För att mätningarna skulle bli rättvisa kördes prestandatesterna och återställningarna med den andra servern stoppad; resten kördes med båda igång och den andra i vila.

Minnet är det proportionella minnet (PSS) för mysqld och mariadbd. Disken är datavolymen; båda börjar på ungefär 1 GB eftersom båda guiderna ställer in en redo-logg på 1 GB.

Hastighet

Vi använde sysbench 1.0.20 från Debian på en databas på 1,9 GB, åtta tabeller med en miljon rader, så allt fick plats i cachen. Efter två minuters uppvärmning kördes varje test i 60 sekunder, två gånger, med 1, 4, 16 och 64 klienter. Tabellen visar medelvärdet i transaktioner per sekund:

MySQL läste upp till 15 % snabbare med få klienter; med 64 var de lika. MariaDB låg före i läsning och skrivning från 4 klienter, och var ungefär dubbelt så snabb på ren skrivning.

Det mesta av skillnaden i skrivning kommer från en enda standardinställning. MySQL för en binärlogg över varje ändring, som skrivs till disk vid varje commit, och som replikering och återställning till en viss tidpunkt använder. I MariaDB är den avstängd tills du slår på den. Vi körde skrivtesterna igen med det ombytt, med 16 klienter:

Utan binärlogg i båda var läsning och skrivning lika; med binärlogg i båda låg MariaDB 23 % före. På ren skrivning låg MariaDB 40 till 55 % före i båda fallen. Behöver du binärloggen, för en replika eller för återställning till en viss tidpunkt, slå på den i MariaDB och räkna med den hastigheten, inte den högre.

Samma binärlogg gjorde MySQL långsammare på att läsa in data: att återställa dumpen tog 375 sekunder mot MariaDB:s 177, och att läsa in testdatan 195 mot 124.

Installation och vardag

Båda guiderna är lika långa och byggda på samma sätt, och båda servrarna kom tillbaka av sig själva efter en omstart. Skillnaderna:

• MySQL:s avbild är nästan tre gånger så stor, 952 MB mot 346 MB. Den innehåller också MySQL Shell.
• MySQL behöver en inställning till i vår guide, net.ipv4.ip_nonlocal_bind, för att kunna starta före WireGuard vid uppstart. MariaDB lyssnar på tunneladressen redan innan den finns.
• MySQL lyssnar också på port 33060 för sitt X Protocol, om du inte stänger av det, som vår guide gör.
• Klienten. Debian har ingen MySQL-klient från Oracle. Dess kommando mysql kommer från MariaDB, och det fungerade med båda servrarna, även över TLS.
• Tecken i containern. I MySQL-avbilden pratar podman exec mysql mysql latin1, eftersom avbilden saknar locale. Ett namn med "Å" som skrevs eller skickades in den vägen sparades förvanskat. Dumpar påverkas inte, eftersom de själva anger teckenuppsättning; lägg annars till --default-character-set=utf8mb4. MariaDB:s klient använde utf8mb4.

Minnet gick åt andra hållet än avbilderna antyder: efter en omstart använde MariaDB 1,2 GB och MySQL 800 MB, eftersom MariaDB sätter upp en del av sin cache när den startar. Under last växte båda mot de 4 GB vi gav dem.

Kör inte båda på samma server med 8 GB och 4 GB cache var. Vi gjorde det, och när båda hade fyllt sina cachar stod hela servern still i flera minuter under en återställning i MySQL, medan kärnan letade efter minne. Kör en per server, som guiderna säger, eller halvera båda cacharna.

Samma app i båda

Vi körde en apps schema och frågor via PyMySQL i Python mot båda: en tabell med kunder och en med beställningar, med främmande nyckel, en CHECK, en JSON-kolumn och en kolumn som räknas fram ur JSON med ett index. Det här fungerade likadant i båda:

• främmande nycklar, CHECK och genererade kolumner, som nekade samma felaktiga rader;
• JSON_EXTRACT, JSON_UNQUOTE, JSON_SET, JSON_CONTAINS, JSON_TABLE, JSON_OBJECT, JSON_ARRAYAGG och JSON_SCHEMA_VALID;
• fönsterfunktioner, rekursiv WITH, EXCEPT, REGEXP_REPLACE, GROUP_CONCAT;
• INSERT ... ON DUPLICATE KEY UPDATE med VALUES();
• 'anna astrom' hittade "Anna Åström", eftersom båda jämför text utan hänsyn till skiftläge och accenter från början.

Det här fungerade bara i MySQL, och MariaDB svarade med ett syntaxfel:

• meta->>'$.sku' och meta->'$.tags', MySQL:s kortform för JSON_EXTRACT;
• INSERT ... AS new ON DUPLICATE KEY UPDATE name = new.name;
• underfrågor med LATERAL;
• MEMBER OF, och index på JSON-listor (CAST(... AS CHAR(20) ARRAY)).

Och det här bara i MariaDB: INSERT ... RETURNING, sekvenser och tabeller som sparar sin egen historik (se nedan).

WordPress 7.1.3 installerades med wp-cli mot båda, och att skapa inlägg och kommentarer och att söka och ersätta webbplatsens adress fungerade likadant. WordPress rekommenderar MySQL 8.0 eller MariaDB 10.11 eller nyare, så båda ligger väl inom det.

JSON

I MySQL är JSON en egen typ, som lagras i ett binärt format. I MariaDB är JSON ett annat namn för LONGTEXT, med en kontroll av att texten är giltig JSON:

`doc` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL CHECK (json_valid(`doc`))

Båda nekade 'not json'. Skillnaden syns i vad du får tillbaka. Vi sparade {"b":1, "a":2, "a":3}, med en dubblerad nyckel, i båda:

MySQL sorterar nycklarna, tar bort dubbletter och behåller den sista, och snyggar till mellanslagen. MariaDB behåller texten som den skrevs. För appar som skriver JSON och läser den via JSON-funktionerna fungerar båda. Appar som jämför JSON som text, eller förlitar sig på MySQL:s ->>, märker skillnaden.

Funktioner där de har gått isär

Vi provade var och en på sin egen server:

• Sekvenser (MariaDB): CREATE SEQUENCE invoice_no START WITH 1000 och NEXTVAL() gav 1000, 1001. MySQL saknar sekvenser; använd AUTO_INCREMENT.
• Tabeller med historik (MariaDB): en tabell WITH SYSTEM VERSIONING behöll det gamla priset efter en ändring, och FOR SYSTEM_TIME AS OF visade tabellen som den var en sekund tidigare. MySQL har inget motsvarande.
• Galera (MariaDB): biblioteket för kluster där alla noder tar emot skrivningar finns i avbilden, redo för wsrep_on. Vi byggde inget kluster, det kräver tre servrar.
• Spider (MariaDB), lagringsmotorn som delar upp en tabell över flera servrar, finns inte i den officiella avbilden: INSTALL SONAME 'ha_spider' hittade ingen fil.
• Group Replication och InnoDB Cluster (MySQL): tillägget group_replication installerades, och MySQL Shell 9.7.1 finns i avbilden. Inte heller här byggde vi något kluster.
• Dokumentlager (MySQL): med X Protocol påslaget för testet lade MySQL Shell till JSON-dokument i en samling och sökte i dem, utan SQL. MySQL lagrar samlingen som en tabell med en JSON-kolumn.
• JSON duality views (MySQL): en vy som visar rader som JSON-dokument, med insättningar och ändringar genom den, fungerade i Community-versionen.
• Trådpool: MySQL 9.7.2 Community laddade sitt tillägg thread_pool med plugin_load_add, trots att Oracles sida fortfarande listar Thread Pool under Enterprise Edition. MariaDB har en inbyggd: thread_handling = pool-of-threads slog på den.
• Vektorer: båda har en vektortyp och kan jämföra vektorer, med olika namn på funktionerna.

Konton och lösenord

Nya konton får olika metoder för lösenord:

• MySQL: caching_sha2_password. Den äldre mysql_native_password är inte laddad i 9.7: att skapa ett konto med den misslyckades med Plugin 'mysql_native_password' is not loaded.
• MariaDB: mysql_native_password, den äldre metoden byggd på SHA-1. MariaDB 12.3 har också caching_sha2_password, som ett tillägg du installerar; ett konto som skapades med det loggade in över TLS. Ed25519 och PARSEC, MariaDB:s starkare metoder, finns också i avbilden.

Alla klienter vi använde, MariaDB-klienten, PyMySQL och PHP:s mysqlnd, fungerade med båda. Eftersom MySQL 9.7 inte laddar mysql_native_password kan en gammal klient som bara kan den metoden inte logga in i den.

Konton flyttar inte mellan dem med sina lösenord. MySQL:s lösenordshashar fungerade inte i MariaDB, inte ens med samma metod; skapa kontona igen med sina lösenord.

Flytta och replikera mellan dem

En dump från MySQL till MariaDB lästes in, utom indexet på en JSON-lista, som MariaDB saknar. MariaDB godtog MySQL:s standardsortering, utf8mb4_0900_ai_ci, och gjorde om kolumnerna av typen JSON till sin LONGTEXT med kontroll.

En dump från MariaDB till MySQL gick inte att läsa in. MySQL kände inte till MariaDB:s standardsortering, utf8mb4_uca1400_ai_ci. När vi hade bytt ut den mot utf8mb4_0900_ai_ci nekade MySQL ändå raderna i tabellen med beställningar, eftersom mariadb-dump skriver ut värdena i genererade kolumner, och nekade tabellen med historik.

Replikering från MySQL till MariaDB fungerade fram till första JSON-kolumnen. MariaDB anslöt som replika över TLS, med ett konto med caching_sha2_password, och kopierade nya databaser, tabeller, insättningar, ändringar och borttagningar. Första raden med JSON stoppade den: Slave received unknown field type field 245, MySQL:s binära JSON. Utan JSON-kolumner kan den hjälpa dig genom en flytt från MySQL till MariaDB.

Replikering från MariaDB till MySQL fungerade inte. MySQL har globala transaktions-id:n (GTID) påslagna från början i den här avbilden, och nekade en källa utan dem. Med ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = LOCAL anslöt den, men stannade direkt med Found invalid event in binary log. De två formaten för GTID, uuid:1-870565 i MySQL och 0-2-119448 i MariaDB, har inget gemensamt.

Uppdateringar och säkerhetskopior

Uppdateringar. Båda avbilderna får sina bugg- och säkerhetsrättelser med podman auto-update. MySQL:s LTS-versioner har stöd i 5 år, plus 3 år med utökat stöd, och nästa kommer efter ungefär två år. 9.7 är den sista med den numreringen; nästa får år och månad, som 26.7. MariaDB släpper en version med långtidsstöd varje år, med stöd i tre år: 12.3, från maj 2026, till juni 2029. Båda uppgraderades i våra guider genom att byta taggen på avbilden, MySQL från 8.4 och MariaDB från 11.8.

Dumpar tog lika lång tid, ungefär två och en halv minut för allt med våra guiders skript, och blev lika stora, 768 MB komprimerat. Det var återställningen som var långsammare i MySQL, som ovan. MySQL sparar 30 dagars binärlogg från början; vår guide sparar sju, och i våra tester växte den ändå till 5,1 GB, mer än själva datan. Räkna med diskutrymme för den.

Fysiska säkerhetskopior, som kopierar datafilerna för snabba återställningar av stora databaser, skiljer sig mest. mariadb-backup ingår i MariaDB:s avbild och tog 26 sekunder. MySQL:s eget verktyg, MySQL Enterprise Backup, ingår i den betalda Enterprise Edition, så vår guide använder Percona XtraBackup: en egen avbild på 1,56 GB, 104 till 112 sekunder för samma data, och för 9.7 bara en testversion, 9.7.1-rc1, när vi testade.

Licens och kostnad

Båda servrarna är öppen källkod under GPL version 2 och kostar ingenting. Vem som står bakom dem skiljer sig, enligt deras egna sidor när vi kontrollerade den 14 oktober 2026.

MySQL tillhör Oracle, både koden och varumärket. Oracle säljer också samma server under en kommersiell licens, för produkter där den byggs in, och säljer MySQL Enterprise Edition, med Enterprise Backup, kryptering av data på disk, en brandvägg, granskningsloggar, maskering av data och support dygnet runt. Sidan visar inga priser. I februari 2026 publicerade Percona och andra i MySQL-världen ett öppet brev där de bad Oracle om ett samtal om en stiftelse för MySQL; Perconas brev säger att Oracle minskade MySQL:s personal med ungefär hälften hösten 2025.

MariaDB utvecklas mest av företaget MariaDB plc, som investmentbolaget K1 köpte upp och tog av börsen 2024, tillsammans med MariaDB Foundation, en ideell stiftelse som finansieras av sponsorer. Stiftelsens sida säger att MariaDB Server "will remain Free and Open Source Software licensed under GPLv2, independent of any commercial entities". Allt från företaget är inte öppen källkod: dess databasproxy, MaxScale, har Business Source License, gratis i drift för färre än tre servrar. Företaget säljer också MariaDB Enterprise Server och support.

Inget av valen låser dig vid att betala något. Med MariaDB finns mer av det du kan behöva senare, som verktyg för fysiska säkerhetskopior, trådpool och klusterbibliotek, i gratisversionen.

Vilken ska du välja?

• MariaDB, för WordPress och de flesta PHP-appar, för appar som nämner båda, och när du skriver mycket eller vill ha säkerhetskopiorna från samma avbild. Börja med Kör en MariaDB-databasserver med Podman utan root. En VC-P Alloy kör den med 4 GB cache.
• MySQL, för appar som kräver MySQL 8 eller nyare, eller använder MySQL:s JSON-syntax eller funktioner, och när du vill ha Group Replication eller dokumentlagret. Börja med Kör en MySQL-databasserver med Podman utan root. En VC-P Alloy kör den med 4 GB cache.

Kolla först vad din app säger: "MySQL 5.7 eller MariaDB 10.x" betyder att båda fungerar. Är du osäker, testa appens egen installation mot båda; det tar några minuter med de här guiderna. Att flytta vår testapp från MySQL till MariaDB var en dump och en återställning, medan vägen åt andra hållet krävde att dumpen rättades för hand.