Nio databaser på 2 GB, och den utan server vann.

De flesta databasjämförelser mäter något ingen kör: likformigt genererade rader, smickrande frågor, ett direkt drivrutinsanrop, en siffra med ett X efter.

En applikation pratar inte med en drivrutin. Den pratar genom ett datalager, en behörighetskontroll, ett filter för mjukraderade poster, en sidbrytningshjälpare och en serialiserare.

Så vi behöll allt det och bytte bara ut lagringsmotorn. Samma data, samma frågor, samma index, samma kodväg: SQLite, PostgreSQL, MongoDB, dpdb, MariaDB, MariaDB bakom MaxScale, ScyllaDB, Cassandra, CockroachDB och CouchDB. Nio scenarier, tio omgångar var.

Det nya är maskinen. En tidigare körning gav varje motor en egen server på 32 GB och PostgreSQL vann sju av nio. Den här ger var och en en låda på 2 GB med jämförelseprocessen boende på den — vilket är hur ett av våra system faktiskt driftsätts, och det ändrar svaret.

Det är oavgjort, och de två motorer som delar förstaplatsen kunde knappast vara mer olika. SQLite och PostgreSQL har båda snittplaceringen 1,78 över de nio scenarierna.

De tar sig dit på olika vägar. SQLite vinner sex av de åtta lässcenarierna; PostgreSQL vinner de två andra och blir tvåa i sju av nio. Räknar man bara läsningar har SQLite 1,50 mot PostgreSQLs 1,75.

MongoDB är trea på 3,11 och äger skrivkolumnen helt med 23 900 rader per sekund, 91 % före nästa motor. Den vann inget lässcenario — samma resultat som på de stora maskinerna.

Marginalen i toppen är inte subtil. SQLite läser en rad på dess id på 9,67 ms där PostgreSQL tar 80,8: åtta gånger snabbare över 200 sekventiella uppslag, det bredaste glappet den här jämförelsen någonsin producerat mellan två fungerande motorer. Den tar sig dit genom att inte vara en server. Det finns ingen port, ingen socket, ingen tur och retur och ingen andra process som slåss om den enda kärnan.

250 000 genererade poster per motor, i en egen databas, seedade från tomt. Sex identiska sekundärindex överallt, på plats medan raderna skrevs.

Varje motor fick en egen maskin: en vCPU, 2 GB, 50 GB disk, i samma datacenter. Varje låda skapades för sin motor, mättes, och förstördes så snart dess siffror var i säkerhet.

Jämförelseprocessen kördes PÅ den lådan, bredvid motorn, genom hela varje omgång. Det är premissen snarare än en kompromiss — applikationen och dess databas delar en maskin, så mätningen bör göra det också.

Varje motor hölls till samma 1 GB hur många processer den än fördelar dem över: MariaDBs buffertpool, ScyllaDBs Seastar-allokering, dpdbs heap, MaxScale bredvid den MariaDB den står framför. Det är utjämning, inte trimning.

Tio fulla omgångar var — töm, seeda om, kör om. Publicerade siffror poolar varje råmätning i stället för att medelvärdesbilda omgångarnas medianer: 100 iterationer per lässcell, 500 styckmätningar per skrivcell.

Innan någon tid rapporterades måste varje motor rymma exakt 250 000 rader och bära exakt den deklarerade indexuppsättningen, kontrollerat mot dess egen katalog i början av varje omgång.

Tre motorer tog sig inte igenom det helskinnade, och var och en behandlas där det hände i stället för att döljas: CockroachDB slutförde sju omgångar av tio, CouchDB slutförde tio och vägrade två scenarier i var och en av dem, och FerretDB slutförde aldrig en enda seedning.

En fyllning från tomt, femtio stycken om femtusen, alla sex index redan på plats.

MongoDB 23 900 rader per sekund — 12,8 sekunder för hela fyllningen, och den enda kolumn den vinner.

ScyllaDB 3 380, vilket är 81 sekunder för samma arbete. Motorerna byggda för att sprida skrivningar över ett kluster betalar mest för att få en nod och en kärna.

CockroachDB är sist på 1 140 rader per sekund — 286 sekunder per fyllning, tjugotvå gånger MongoDBs, och skälet till att den bara slutförde sju omgångar. Raft-konsensus och en serialiserbar transaktion på varje insättning är inte gratis på en kärna.

Tvåhundra sekventiella uppslag på primärnyckel. Scenariot som skiljer fältet mest åt, och det skiljer det med en faktor 125.

SQLite 9,67 ms mot PostgreSQLs 80,8. CouchDB är sist på 1 210 och dpdb näst sist på 428.

Båda ändarna har samma orsak. SQLite svarar inuti processen som frågade, så ett uppslag är ett funktionsanrop; dpdb svarar över HTTP till en andra process, så ett uppslag är ett anrop. Tvåhundra sekventiella turer är tvåhundra tillfällen att betala för det, och det är den enda form där skillnaden är hela mätningen. CouchDB, som talar HTTP av konstruktion, sitter i andra änden av samma axel.

Ett indexerat uppslag på en främmande nyckel som returnerar 494 rader — den vanligaste frågan den här applikationen ställer.

SQLite 3,41 ms, PostgreSQL 7,97, MongoDB 11,2. Cassandra är sist av motorerna som svarade, på 22,1.

CouchDB besvarade den inte alls. I alla tio omgångarna kom frågan tillbaka från servern som en timeout — CouchDB som vägrar köra den snarare än kör den långsamt, vilket är beteendet den dokumenterar och det enda på den här sidan som inte är en siffra.

Här ligger sidans jämnaste avgörande: dpdb 18,3 ms mot MariaDB 18,8, ett glapp på 2,7 % mellan två motorer som kördes på två olika maskiner. Behandla det paret som oavgjort.

Femtio rader sorterade på datum, fallande. Det en användare ser när hen öppnar en lista.

SQLite 2,88 ms och PostgreSQL 3,85 är snabba nog att nätverket ut till webbläsaren kostar mer än frågan.

ScyllaDB 28,2, Cassandra 39,8 och CockroachDB 46,6: en godtycklig sortering är inte vad CQL är byggt för, oavsett maskinstorlek, och en distribuerad SQL-motor på en nod får ingen kompensation för maskineriet.

Det här är CouchDBs andra vägran. En Mango-sortering behöver ett index som täcker den, och i stället för att degradera avstår motorn.

Samma femtio rader, tiotusen ner. PostgreSQLs första vinst, och det tydligaste den gör bättre än SQLite.

PostgreSQL 4,99 ms, MongoDB 11,6, SQLite 17,4. En djup offset är där en riktig frågeplanerare och en riktig buffertpool tjänar in sitt minne. Det här och den exakta räkningen är de enda två läsningar SQLite inte vinner, och den förlorar båda mot samma två motorer.

ScyllaDB 249 ms och Cassandra 201. CQL har ingen OFFSET, så djup sidbrytning emuleras.

CouchDB tar 20,4 sekunder — fyratusen gånger PostgreSQL, och det bredaste enskilda glappet någonstans i den här jämförelsen.

Tiotusen rader som matchar ett booleskt fält utan index på någon motor. Alla läser igenom, så det här mäter genomsökningshastighet och inget annat.

SQLite 75,1 ms, PostgreSQL 141. ScyllaDB 418 och MariaDB 405 — att söka igenom är det CQL är minst villigt att göra, och InnoDB är inte mycket gladare över det här.

CouchDB 4,7 sekunder, och dess p95 är 10,5: ungefär ett anrop av tjugo kostar mer än dubbelt det typiska, vilket är sidans bredaste svans.

Ett indexerat uppslag och en numerisk jämförelse tillsammans — frågan en rapport byggs av.

SQLite 2,03 ms, PostgreSQL 3,95, MongoDB 5,83. Sidans snabbaste siffror, på de minsta maskiner den här jämförelsen använt.

CockroachDB 23,5 och CouchDB 315 avslutar den.

Hur många rader finns det. Den enklaste frågan här, PostgreSQLs andra vinst, och den enda läsning där SQLite slås med klar marginal — 99 ms mot 437.

MongoDB 156 ms. MariaDB 1,75 sekunder, därför att InnoDB inte håller något exakt radantal och COUNT(*) läser igenom ett index för att få fram det — samma beteende den visade på en maskin med 32 GB, i samma multipel.

ScyllaDB och Cassandra kan inte besvara den som ett enda anrop alls, så deras siffra är en sidbruten genomsökning: 1,62 och 2,79 sekunder.

CouchDB 32,4 sekunder. Den håller en databas per samling, vilket borde göra en exakt räkning till en metadataläsning; på den här maskinen är den inte det.

Alla 250 000 rader, genom applikationen, serialiserade.

SQLite 2,37 sekunder, PostgreSQL 3,02, ScyllaDB 3,72, CockroachDB 4,10. dpdb 7,64, och CouchDB 56,4 — tjugofyra gånger vinnaren.

ScyllaDB är värd en andra blick här: näst sist på den djupa sidan, tredje snabbast på att strömma hela samlingen, och den passerar MongoDB på vägen. Sekventiella massläsningar är åtkomstmönstret den byggdes kring, och det här är sidans enda scenario som ber om dem.

MariaDB kördes två gånger: direkt, och genom MaxScale på samma maskin med samma rader och samma inloggning. Porten är den enda skillnaden, så varje glapp mellan de två kolumnerna är proxyn.

Det är ingen platt skatt, och den går inte ens åt ett håll. Punktläsningen — 200 sekventiella turer — kostar 31 % mer genom MaxScale. Allt som returnerar en bunt kommer tillbaka snabbare: relationsuppslaget med 28 %, det oindexerade filtret med 27 %, hela inläsningen av 250 000 rader med 28 %.

Den exakta räkningen och massinläggningen är identiska med den rapporterade siffran.

Den tidigare körningen mätte samma två riktningar på maskiner med 32 GB och en helt annan processor: 18,7 % långsammare på punktläsningen, 29 % snabbare på hela inläsningen. Att få tillbaka båda halvorna på en sextondel av minnet och en åttondel av kärnorna är ett starkare påstående än någondera körningen gör ensam.

Den troliga orsaken till vinsten på bunten är att proxyn frikopplar läsningen från motorn från skrivningen till klienten. Det är en hypotes; mätningen är det inte.

Två motorer besegrades av maskinen snarare än av varandra, och båda är värda mer än placeringen de hamnar på.

CockroachDB slutförde sju omgångar av tio. Två dog med att uppkopplingen bröts mitt i en seedning, och en hängde sig hela takgränsen på tre timmar utan att producera något alls. Dess kolumn är poolad ur de sju som överlevde, vilket smickrar den: omgångarna den förlorade är de där den hade problem.

FerretDB har ingen kolumn alls, och det är dess resultat snarare än en lucka i vårt.

Den slutförde aldrig en enda seedning på den här hårdvaran. Kärnans OOM-dödare tog den vid 783 MB med 50 100 av 250 000 rader skrivna, och den tog den igen vid varje uppdelning av minnesbudgeten vi försökte med.

Det som dödar den är formen på en översättande proxy: den svarar genom att materialisera en hel samling inuti processen som översätter, så dess minnesbehov följer datamängdens storlek snarare än sidans. På 32 GB är det osynligt och den slutförde varje scenario. På 2 GB är det fyndet.

Siffran som hade fått den att rymmas är skälet till att den inte har någon. Varje annan kolumn hålls till samma 1 GB, och en motor som mätts med mer är inte mätt mot dem.

CouchDB hör bara halvvägs hemma här. Den slutförde alla tio omgångarna och vägrade sedan två av de åtta lässcenarierna i var och en av dem — relationsuppslaget och första sidan, båda returnerade av servern som timeouts. De sex den besvarar, besvarar den sist.

Nog för att spela roll i botten av tabellen och inte på långa vägar nog för att spela roll i toppen.

Varje motor kördes på en egen maskin. De är samma produkt i samma datacenter, men den här flottan registrerade ingen kalibrering mellan maskiner — flottan med 32 GB gjorde det, och fann en spridning på 4,2 % mellan nominellt identiska servrar. Anta något i den storleksordningen här och läs allt inom några procent som oavgjort.

Två avgöranden ligger innanför det: dpdbs relationsuppslag på 18,3 ms mot MariaDBs 18,8, och ScyllaDBs intervallsökning på 11,7 ms mot dpdbs 12,2. Ingetdera flyttar en placering ovanför femte.

Inget nära toppen är i fara. SQLites punktläsning är åtta gånger nästa motors och dess smalaste vinst är 34 %; ingen rimlig skillnad mellan två lådor av en produkt når någondera.

CockroachDBs kolumn bär ett andra slags fel de övriga inte har: 70 mätvärden per cell i stället för 100, hämtade ur omgångarna den överlevde. Det är en välvillig uppskattning av en motor som inte kom i mål, och den ska läsas som en.

Proxyjämförelsen är den enda på sidan utan någon maskin i sig alls — MaxScale och MariaDB är en server på en låda, och porten är hela skillnaden.

Varje anrop var sekventiellt och varje motor körde en nod. Inget här beskriver beteende under samtidighet eller över ett kluster, vilket är där ScyllaDB, Cassandra och CockroachDB är byggda för att löna sig — och en enkärnig låda är den minst representativa maskin som finns för någotdera.