phpMyAdmin alternatieven in 2026: native versus browser

Het is 23:05 op een vrijdag. Een WordPress-site die we vorige maand hebben overgenomen geeft WSOD na een automatische plugin-update, en de enige ingang is het cPanel dat bij de hosting zit. Je klikt op het phpMyAdmin-icoon, krijgt eerst een self-signed cert-waarschuwing, logt in, kiest de juiste database uit een dropdown van 41 databases (de host zet alle klanten op één gedeelde MySQL-gebruiker) en staart naar de wp_options-tabel. Je moet active_plugins terugzetten op de vorige geserialiseerde waarde. De cel is 14 KB. De textarea is 80 kolommen breed. Er is geen undo.

Dit is het moment waarop mensen op zoek gaan naar phpMyAdmin-alternatieven. Niet omdat phpMyAdmin stuk is, niet echt. Het werkt. Het werkt al sinds 1998. Maar het tab-in-een-browser-model dat logisch was toen het alternatief inloggen op mysql via een 56k-lijn was, is verouderd tot iets dat je elke keer minuten kost als je het aanraakt, en af en toe een kolom.

Waar phpMyAdmin echt goed in is

Eerlijk is eerlijk. phpMyAdmin is de meest draagbare MySQL-client op de planeet. Hij zit standaard in cPanel, Plesk, DirectAdmin, ISPConfig, MAMP, XAMPP, Laragon, en ongeveer elke shared host van €3 per maand die ooit bestaan heeft. Als een klant je inloggegevens en een IP geeft, heb je binnen 90 seconden een query-venster open zonder iets te installeren. Voor losse opzoekingen, een snelle blik op het schema, of het exporteren van één tabel naar SQL voor een migratie is hij eigenlijk prima.

Het is ook de kleinste gemene deler die je klanten begrijpen. "Open phpMyAdmin en plak dit" is een zin die je tegen een niet-technische site-eigenaar kunt zeggen en die dan ook werkt. Dat is wat waard.

Waar het stukloopt op een legacy-stack

Het echte probleem begint zodra het werk serieus wordt. Een paar specifieke faalmodi die ik dit jaar allemaal ben tegengekomen bij het redden van een legacy site.

Het 14 KB-textarea probleem

WordPress slaat geserialiseerde PHP op in wp_options. Drupal slaat geserialiseerde config op in cache_*-tabellen en variable. Magento 1 stopt XML-blobs in core_config_data. phpMyAdmin laat die zien als een textarea met vaste hoogte, zonder enig besef van syntax. Je kunt niets inklappen, niets diffen, en als je een waarde plakt met een verdwaald karakter geeft maybe_unserialize() false terug en is je site wit. Geen preview, geen validatie, geen "dit lijkt op een geserialiseerde array, zal ik hem parsen?"-hulp.

Geen echte version history

phpMyAdmin heeft een SQL-historiepaneel in de zijbalk, maar dat logt jouw queries, niet de rijen die je veranderd hebt. Als je om 23:11 UPDATE wp_options SET option_value = '...' WHERE option_id = 42 draaide en je wilt weten wat de waarde om 23:10 was, dan ligt het antwoord in je laatste databaseback-up, als die er is. De meeste shared-host back-ups zijn 24-uurs, en "de hele database terugzetten" is geen passend antwoord op "ik wil één cel terug".

PHP-execution limits lekken je tooling in

Omdat phpMyAdmin in dezelfde PHP-FPM pool draait als de site, zijn de limieten van phpMyAdmin de limieten van de site. Een mysqldump-achtige export van een 2 GB Magento sales_flat_order-tabel knalt tegen max_execution_time = 30 aan en sterft met een half bestand. De standaard workaround is een eigen php.ini naast phpMyAdmin zetten of de "large database"-vlag van de host gebruiken, en die laatste biedt lang niet iedere host. Vergelijk dat met een dump streamen via SSH met mysqldump --single-transaction --quick, die maakt het niet uit hoe lang het duurt.

Het inlogoppervlak

Als jij /phpmyadmin kunt bereiken, kan een botnet dat ook. Het eerste op elke fatsoenlijke hardening-checklist is het pad hernoemen, beperken op IP, of er HTTP basic auth voor zetten. Een minimale .htaccess in de phpMyAdmin-map:

<RequireAll>
  Require ip 81.207.0.0/16
  Require ip 2001:1c00::/32
</RequireAll>

AuthType Basic
AuthName "Restricted"
AuthUserFile /home/site/.htpasswd-pma
Require valid-user

Dit werkt, maar nu heb je er een credential om te roteren bij en een IP-allowlist om te onderhouden over elke klant heen. OWASP noemt blootgestelde admin-interfaces al sinds de eerste Top 10 als terugkerende aanvalsvector. De goedkoopste oplossing is er gewoon geen hebben.

Het veld van alternatieven in 2026

Het landschap is genoeg veranderd sinds de meesten van ons hier voor het laatst doorheen liepen, een verse blik is de moeite waard.

Browser-based, zelf gehost

Adminer is de voor de hand liggende phpMyAdmin-vervanger: één PHP-bestand, sneller, schonere UI, hetzelfde deployment-model. Als je enige eis is "ik wil phpMyAdmin maar dan minder", is Adminer het antwoord. Hij erft dezelfde problemen rond PHP-execution limits en een blootgesteld admin-oppervlak.

CloudBeaver is de browserversie van DBeaver. Zwaarder om te hosten (Java), maar multi-database. Handig als je een klein bureau runt met één gedeelde editor over Postgres, MySQL en SQLite.

Native desktop clients

Sequel Ace (de onderhouden fork van Sequel Pro) is nog steeds de standaardkeuze op macOS voor rauwe MySQL. Gratis, snel, geen poespas. Zwakte is dezelfde als bij elke algemene client: hij weet niets van WordPress, Drupal of Magento, dus een geserialiseerd active_plugins-veld blijft een ondoorzichtige blob.

TablePlus is de gepolijste commerciële optie. Uitstekende UX, multi-database, ondersteunt SSH-tunneling out of the box. Closed source, betaald, en ook hier geen CMS-besef.

DBeaver Community is de Java-client met alles erop en eraan. Krachtig, lelijk, ondersteunt meer drivers dan je ooit gaat gebruiken. De moeite waard om geïnstalleerd te hebben voor de dag dat je iets exotisch overneemt.

De CLI, nog steeds

Voor destructieve operaties op productie pak ik altijd mysql via SSH erbij voordat ik een GUI aanraak. Het tweestappen-patroon is:

ssh user@host
mysqldump --single-transaction --quick \
  --databases sitedb \
  --tables wp_options \
  > /tmp/wp_options.$(date +%s).sql
mysql sitedb < fix.sql

Het is niet mooi, maar de gewoonte om eerst een dump te maken voordat je iets aanraakt heeft me vaker gered dan welke clientfunctie dan ook.

De criteria die echt tellen

Als je in 2026 één tool kiest voor legacy CMS-werk, de vragen waarop ik zou scoren, op volgorde:

1. Overleeft hij de verbinding? Veel van de slechtste hosts laten MySQL alleen op 127.0.0.1 binnen, dus de client moet via SSH of SFTP kunnen tunnelen zonder dat jij er een script voor hoeft te schrijven.
2. Begrijpt hij geserialiseerde PHP en JSON? Een wp_options-blob bewerken zonder parser is een voetzoeker.
3. Kun je één rij ongedaan maken? Niet "de database terugzetten". Deze cel ongedaan maken, terug naar de waarde van twee minuten geleden.
4. Is het admin-oppervlak weg van het publieke internet? De beste /phpmyadmin-hardening is geen /phpmyadmin.
5. Gaat een junior er de productie mee slopen? Een client zonder autocommit = 0 en zonder bevestiging op bulk updates is een client waarmee uiteindelijk iemand UPDATE users SET email = 'x' draait zonder WHERE.

Waar een native client de browsertab verslaat

Trek de draden samen en de zaak voor een desktop-client boven phpMyAdmin in 2026 draait grotendeels om drie dingen: de verbinding leeft op jouw machine in plaats van op de server, de editor weet waar hij naar kijkt, en je wijzigingen worden lokaal bijgehouden zodat undo een toetsaanslag is in plaats van een back-up restore. Geen daarvan vereist nieuwe technologie. Ze vereisen de aanname dat een database iets is waar je vanuit werkt, niet iets waar je op inlogt.

Toen we de MySQL editor van Pier bouwden liepen we precies hier tegenaan op een Drupal 7-site die we aan het redden waren: een variable-rij werd verkeerd bewerkt in phpMyAdmin, de site ging plat, en de laatste back-up was 19 uur oud. Hoe we het uiteindelijk oplosten was elke cel-edit wikkelen in een lokale version history zodat de vorige waarde één klik weg is, en de editor leren wat geserialiseerde PHP en JSON zijn zodat de textarea geen valstrik meer is.

Het kleinste wat je vandaag kunt doen: kies één klantsite, open de wp_options-tabel in de tool die je nu gebruikt, en probeer te achterhalen waar siteurl een week geleden op stond. Als het antwoord is "een back-up terugzetten", heb je een tooling-gat dat je beter dicht voordat het volgende vrijdagavondincident komt.