Je database is geen huisdier

De DBA die zijn servers een naam gaf

We kennen hem allemaal. Misschien was jij er één. De DBA met een server genaamd “Brutus”, een kritieke productiedatabase, documentatie uitsluitend in zijn hoofd, back-upstrategie gebaseerd op een cronjob en optimisme.

Als Brutus omvalt, moet de DBA hem opvangen. De organisatie houdt zijn adem in. Niets beweegt totdat hij weer online is, ingelogd via ssh, queries uit zijn geheugen typend.

Dit is het huisdierprobleem. Eén specialist. Eén server. Nul veerkracht.

De oplossing, zo zei iedereen, was automatisering. Kubernetes-operators. Managed clouddatabases. Infrastructure as code. Laat het platform het regelen. Stop met je database als een huisdier behandelen.

Prima. Daar zijn we het mee eens. Alleen liep het vervolgens mis.

Wanneer vee een probleem wordt

We lopen regelmatig binnen bij organisaties die de stap hebben gemaakt, van on-premises huisdieren naar volledig managed clouddatabases. RDS, Azure Database for PostgreSQL, Cloud SQL. Geautomatiseerde back-ups. Automatische failover. Geen Brutus meer.

Zes maanden later zijn de queries traag. De cloudrekening stijgt. Autovacuum draait op verkeerde momenten en vergrendelt tabellen tijdens piekuren. Connection-pools zijn verkeerd geconfigureerd. Indexes die logisch waren bij het oude schema werken nu tégen je. Niemand heeft het gemerkt, want het dashboard staat op groen.

De vee-mentaliteit nam volledig over. De database werd een nummer. Niemand keek nog van binnen.

Precies daar zit het probleem: een managed database is geen geoptimaliseerde database. Je cloudprovider regelt patching, failover en back-ups. Die tunet jouw queries niet. Die analyseert jouw index-bloat niet. Die trekt zich niets aan van het feit dat je autovacuum-instellingen zijn geconfigureerd voor een database van 10 GB die inmiddels 400 GB is. Dat is hun taak niet.

Het is die van jou. Of het zou iemands taak moeten zijn.

Wat er wél aandacht nodig heeft

Als wij een QuickScan doen op een cloud-managed database, of dat nu PostgreSQL op RDS is, Azure SQL of een zelf beheerde Kubernetes-omgeving met CloudNativePG, zien we telkens dezelfde categorieën problemen. Voorbeelden:

Query-performance. Het slow-query-logproces is niet mee gemigreerd. Queries die on-prem actief werden getuned, draaien nu gewoon. Langzaam.

Indexstrategie. Indexes gekopieerd vanuit de oude omgeving. Indexes die “voor de zekerheid” jaren geleden zijn toegevoegd. Dubbele indexes. Ontbrekende indexes op kolommen die inmiddels join-keys zijn. Index-bloat op tabellen met veel schrijfactiviteit die nooit worden opgeschoond.

Autovacuum en bloat. PostgreSQL’s autovacuum is krachtig, mits correct geconfigureerd voor jouw werkbelasting. Standaardinstellingen zijn ontworpen voor een generieke baseline. Een productieomgeving met veel schrijfactiviteit is niet generiek.

Verbindingsbeheer. On-prem had iemand PgBouncer geconfigureerd. Tijdens de cloudmigratie is dat overgeslagen. Nu heb je 400 directe verbindingen naar een db.t3.medium en vraag je je af waarom het piept en kraakt.

Observability. Metrics zijn er. Dashboards zijn er. Niemand heeft gedefinieerd wat “slecht” eruitziet. Alerts gaan af bij infrastructuurgebeurtenissen, niet bij databasegedrag.

Niets van dit alles lost je cloudprovider voor je op. Niets hiervan verschijnt als rood in de AWS-console.

Het juiste mentale model

Je database is geen huisdier. Je hebt geen specifiek persoon nodig om hem levend te houden via stammenkennis en nachtelijke heldendaden.

Het is ook geen anoniem stuk vee. Je kunt hem niet taggen, de infrastructuurlaag automatiseren en ervan uitgaan dat alles goed draait.

Zie het meer als een racemotor. Je hoeft hem niet elke keer met de hand te bouwen. Je hoeft hem geen naam te geven. Je hebt wel iemand nodig die weet wat hij ziet, die regelmatig kijkt, die hem afstelt op de omstandigheden waarin hij werkelijk draait en die merkt wanneer er iets stil misgaat voordat het een crisis wordt.

Dat is wat een Database Reliability Engineer doet. Geen babysitwerk. Geen brandjes blussen. Het systeem goed genoeg kennen om het optimaal te laten draaien, geautomatiseerd waar het kan, vakkundig waar het moet.

Hoe dat er in de praktijk uitziet

We zien drie patronen die werken.

Regelmatige healthchecks. Niet alleen infrastructuur-monitoring, maar een DBA-level review van query-plans, indexgebruik, bloat en configuratiedrift. Elk kwartaal minimaal. Maandelijks voor systemen met veel verkeer.

Goede observability. pg_stat_statements, slow-query-logging, autovacuum-monitoring, verbindingsregistratie. Niet alleen “doet de database het?” maar “presteert de database?”

Een mens in de loop. Niet iemand die de database bezit als een huisdier, maar iemand die hem goed genoeg begrijpt om goede beslissingen te nemen. Intern of extern, dat maakt niet uit. Wat telt is dat er iemand écht kijkt.

De kern

Het huisdier-versus-vee-debat ging nooit echt over databases. Databases zijn stateful, complex en nauw verbonden met applicatiegedrag. Ze vragen een ander soort aandacht dan een webserver of een API-container.

Er is in de basis niets mis met Database as a Service. Automatisering is een goede zaak. Ze lossen alleen infrastructuurproblemen op, geen databaseproblemen.

Als jouw database in de cloud draait, volledig “managed”, zonder dat iemand hem actief tunet en reviewt, dan ben je misschien af van je huisdierprobleem, maar heb je nu de problemen van een veehouderij. Je hebt het ene risico ingeruild voor een ander.

Wij helpen organisaties de juiste balans te vinden, geautomatiseerd waar het zinvol is, vakkundig waar het ertoe doet. Herken je dit? Neem gerust contact op. Vrijblijvend, zoals altijd.