Tidigt i min karriär var jag mycket intresserad av NoSQL-databasen MongoDB. Det är en dokument-orienterad databas som lagrar data i dokument med en JSON-lik struktur. Även frågor och aggregationer använder denna JSON-dialekt. Detta kombinerat med flexibla och dynamiska scheman samt inbyggt stöd för sharding och replikering gjorde MongoDB till en väldigt populär NoSQL-databas när den släpptes.
Jag själv blev mycket tagen av hur enkelt det var att komma igång med databasen jämfört med alternativen MySQL och PostgreSQL och skrev till och med min kandidatuppsats om databasen och dess styrkor och svagheter i ett CMS-företags kontext.
Med tiden så började dock de många och allvarliga nackdelarna och problemen med MongoDB spridas och diskuteras runt om på internet. För mig personligen blev det särskilt tydligt när jag och en kollega jobbade på ett årslångt projekt med MongoDB i centrum och utkämpade en sisyfonsk kamp mot buggar, korrupt data och krascher. Samtidigt så började industrin mogna i sin användning av NoSQL-databaser, där användarna började flockas till ett fåtal databaser vars utveckling drevs av stora och erfarna aktörer som Amazons DynamoDB, Apaches Cassandra och Elastics ElasticSearch.
Det som gjorde MongoDB så populärt när den släpptes var i min åsikt främst tre faktorer: 1) bristande kunskaper om distribuerade system, 2) stagnerade relationsdatabaser och 3) ett flexibelt schema.
Den första punkten handlar om att många bolag vid tiden då MongoDB släpptes var i processen att migrera stora monolitiska applikationer till distribuerade system. MongoDB var medvetna om detta och fokuserade på att göra databasen enkel att skala horisontellt genom sharding och replikering. Tyvärr så lades fokuset på “convention over configuration”, alltså att ett antal förbestämda användningsfall var enkla att åstadkomma, medan avvikande scenarier var mycket svårare att lösa.
Den andra punkten handlar om att relationsdatabasmarknaden vid denna tid dominerades av ett antal mycket stora aktörer med dåliga erbjudanden och stagnerad teknik, främst Oracle, IBM och Microsoft. Både MySQL och PostgreSQL hade redan funnits ett antal år vid denna tid, men fokuserade fortfarande på feature-parity med de stora databaserna framför innovation. Bristen på stöd för horisontell skalning och scheman som var svåra att anpassa för snabb tillväxt och ändrade krav ledde till ett missnöje som drev utvecklare mot MongoDB.
Den tredje punkten handlar om det som oftast kallades för MongoDBs killer feature: helt flexibla scheman. Genom att på utsidan representera scheman med JSON och låta användare skapa dokument utan krav på att alla dokument har samma struktur så gav man användarna en frihet och flexibilitet som ingen av konkurrenterna erbjöd, samtidigt som det vid den tiden familjära JSON-formatet tilltalade frontendutvecklare.
Med tiden så kom dock de tre öppna databaserna ikapp feature-mässigt. Med tiden fick MySQL, MariaDB och PostgreSQL stöd för XML- och JSON-kolumner vilket gav dem stöd för flexibla scheman. Även key-value-lagring implementerades i MariaDB och PostgreSQL. I skrivande stund finns stöd för replikering implementerat i de tre ovan nämnda databaserna, och i vissa fall även sharding. Detta gör att dessa tre yngre relationsdatabaser i dagsläget har en mycket starkare ställning gentemot NoSQL-databaserna än tidigare.
Idag har även jag kokat ner min tidigare breda repertoar av databaser till ett fåtal alternativ som tillsammans kan hantera den stora majoriteten av användningsfall. Står man inför en uppgift som innehåller data med många relationer, krav på säkra transaktioner samt eventuella inslag av dokument med flexibla scheman så rekommenderar jag PostgreSQL med sin massiva verktygslåda av kolumner och datatyper. I resurssnåla miljöer som mobiler eller inbyggda system finns det utmärkta SQLite att tillgå. Har man istället en uppgift som kräver snabba svar på relativt enkla frågor samt kraftigt växande mängder data så rekommenderar jag DynamoDB eller Cassandra med sina kraftfulla inställningar för partitionering och skalning.
Avslutningsvis så kan jag inte längre rekommendera någon att använda MongoDB för något användningsfall. Allt det som MongoDB kan göra kan andra databastekniker göra antingen bättre, snabbare eller säkrare. Tack vare tekniker som Docker kan vi dessutom skapa färdigkonfigurerade och körbara instanser av databaser med en enda rad kod, vilket betydligt sänkt tröskeln för att använda dem för prototyping. Med allt det sagt så har MongoDB ändå gjort ett betydande bidrag till industrin: det har sporrat andra databaser att snabba på sin utveckling och möta konkurrensen med nya och bättre erbjudanden.
