Det korta svaret
Välj FerretDB om du vill spara dokument på ett enkelt sätt under en licens med öppen källkod, och din app varken behöver transaktioner eller change streams och är ensam om databasen. Välj MongoDB för allt som bygger på transaktioner, change streams, schemavalidering eller en inloggning per app som bara når sin egen databas: i våra tester godtog FerretDB allt det där utan att göra det, och MongoDB var dessutom snabbare på det mesta.
Det här testade vi
Vi installerade båda på samma nya Melonslab VC-P Alloy (2 vCPU, 8 GB) med Debian 13, den ena efter den andra, och följde våra guider FerretDB-databasserver och MongoDB-databasserver steg för steg. De körde under var sin användare, med TLS, lösenord och de inställningar för 8 GB minne som varje guide ger.
Båda guiderna publicerar port 27017. För att köra båda på samma server ändrade vi bara de två raderna PublishPort i FerretDB:s ferretdb.pod till 127.0.0.1:27018:27017 och 10.8.0.1:27018:27017, och öppnade 27018 på wg0 i ufw också. Inne i podden lyssnar FerretDB fortfarande på 27017, så guidens alias för mongosh och skriptet för säkerhetskopiering fungerar som de är. Kör du bara en av dem behåller du guiderna som de står.
Sedan körde vi samma Python-kod, med PyMongo 4.10, mot båda:
- ett skript som provar inloggningar, transaktioner, change streams, vyer, collation, validering med mera, och jämför resultaten;
- ett prestandatest med 105 000 ordrar och 5 000 kunder: att lägga in dokument, sökningar med index, en aggregering, en join och en blandning av ändringar och läsningar, tre gånger på var och en;
- den lilla anteckningsappen från båda guiderna, via WireGuard-adressen.
Vi mätte också minnet efter en omstart, disken och säkerhetskopiorna och återställningarna från varje guide, och flyttade en dump från var databas till den andra.
Siffrorna
| FerretDB 2.7.0 | MongoDB 9.0.2 | |
|---|---|---|
| Containrar | 2: FerretDB, PostgreSQL 17.6 med DocumentDB 0.107.0 | 1: MongoDB |
| Minne i vila efter omstart | omkring 95 MB (FerretDB 7, PostgreSQL 19, plus 66 MB av PostgreSQL:s delade cache) | omkring 210 MB |
| Minne efter frågorna | omkring 155 MB | omkring 200 MB |
| Gräns för cachen i guiden | 2 GB (shared_buffers) | 3 GB (wiredTigerCacheSizeGB) |
| Avbilder på disken | 1,78 GB, plus 1,09 GB för avbilden mongo med verktygen | 1,09 GB |
| Data på disken efter prestandatestet | omkring 1 GB, varav 880 MB PostgreSQL:s transaktionslogg | 285 MB, varav 200 MB MongoDB:s journal |
| Samma data, nyss återställd | 133 MB | 224 MB |
Samlingar och index (dbStats) | 50 MB och 21 MB | 18 MB och 7 MB, komprimerat |
| Första start, med nedladdning av avbilder | omkring 1 minut och 45 sekunder | omkring 55 sekunder |
| Steg i vår guide | 11 | 11 |
| Nattlig säkerhetskopia | 9 sekunder: en dump, 3,9 MB, och en kopia av PostgreSQL, 12,8 MB | 2,5 sekunder: en dump, 3,9 MB |
| Återställa en databas från dumpen | 11 sekunder | 8 sekunder |
| Återställa allt till en tom volym | 17 sekunder | 25 sekunder |
Minnet är mätt i varje apps egna kontrollgrupper. podman stats visar omkring 20 MB för PostgreSQL, eftersom den inte räknar det delade minne som PostgreSQL använder som cache. Båda cacharna växer när din data används, upp till gränserna ovan. Hela servern, med båda igång och testdatan inläst, använde 780 MB efter en omstart.
Siffrorna för disken beror på vad du har gjort nyligen. PostgreSQL behåller som standard upp till 1 GB transaktionslogg och återanvänder den, så efter många skrivningar nådde FerretDB:s volym omkring 1 GB. MongoDB:s journal tar omkring 200 MB från början. Nyss återställd, utan historik, tog FerretDB mindre.
Kompatibilitet
Vi körde ett och samma skript mot båda. Raderna är vad det provade, och cellerna vad som hände.
| Det här provade vi | FerretDB 2.7.0 | MongoDB 9.0.2 |
|---|---|---|
| Appens inloggning läser en annan apps databas | tillåts | nekas, not authorized |
| Appens inloggning skriver i en annan apps databas | tillåts | nekas, not authorized |
Skapa en inloggning som bara får läsa, med createUser | misslyckas, inloggningar skapas i PostgreSQL | nekas för appens inloggning, fungerar för admin |
| En skrivning i en transaktion, sedd utifrån före commit | syns | syns inte |
Samma skrivning efter abortTransaction | finns kvar | borta |
Change stream (watch()) | misslyckas: $changeStream is not supported yet | fick händelsen |
| En vy med 3 av 5 dokument | skapades, gav 0 | gav 3 |
Sökning utan hänsyn till versaler med collation({locale: "sv", strength: 2}) | hittade 0 av 2 | hittade 2 av 2 |
En validator med $jsonSchema, sedan ett dokument som bryter mot den | sparades ändå | nekades, Document failed validation |
Capped collection med max: 3, 10 dokument in | 10 dokument | 3 dokument |
| Time series-samling | blev en vanlig samling | en time series-samling |
| Dolt index | misslyckas: not supported yet | fungerade |
collMod för att lägga till en validator eller ändra en TTL | misslyckas | fungerade |
Profileraren (profile) | misslyckas: no such command | fungerade |
mapReduce | misslyckas: no such command | fungerade |
$where | misslyckas | nekas, som MongoDB 9.0 gör som standard |
Textsökning, $lookup, $near med 2dsphere, TTL- och unika index | fungerade | fungerade |
Steg 9 i FerretDB-guiden listar mer som fungerade på båda, bland annat de flesta aggregeringssteg. Det FerretDB inte klarade nekade den antingen med ett fel, som din app märker, eller godtog och struntade i, som den inte märker. Det andra är det farliga: transaktioner, vyer, collation, validatorer och capped collections såg alla bra ut tills vi kontrollerade resultatet.
Installation
Båda guiderna är byggda på samma sätt: en egen användare, en egen certifikatutfärdare, TLS för varje anslutning, hemligheter i podman secret, åtkomst bara från servern själv och via WireGuard, och en säkerhetskopiering med en timer. Båda fungerade som de stod skrivna.
MongoDB är en container. Den behöver ett replica set med en medlem, som du startar för hand en gång, för att transaktioner och change streams ska fungera, och appar måste lägga till directConnection=true i sin anslutningssträng. Den vill också ha två inställningar i kärnan för transparent huge pages, som dess guide lägger till.
FerretDB är en pod med två containrar, FerretDB och PostgreSQL med tillägget DocumentDB, och kräver lite mer omsorg: en roll i PostgreSQL för FerretDB som skapas vid första starten, minnesinställningar för PostgreSQL och inloggningar som du skapar med psql, eftersom createUser i mongosh inte fungerar. FerretDB skickar också användningsstatistik tills du stänger av den, vilket dess guide gör. Avbilderna är större, och du behöver avbilden mongo också, för mongosh och verktygen för säkerhetskopiering.
I vardagen
För en app ser båda likadana ut. Anteckningsappen från guiderna gick oförändrad mot båda; bara anslutningssträngen skilde. mongosh, mongodump och mongorestore fungerar med båda, och mot FerretDB varnar mongosh att This server or service appears to be an emulation of MongoDB.
Skillnaden är vad som händer när något går fel. I MongoDB kommer en apps inloggning bara åt sin egen databas, en transaktion som misslyckas lämnar inget efter sig, och en validator stoppar felaktiga dokument. I FerretDB kan varje inloggning läsa och skriva i varje databas, och de andra två gör tyst ingenting. Kör du mer än en app behöver varje app en egen FerretDB, med egen användare, pod och port.
MongoDB har också verktygen runt omkring: change streams för uppdateringar direkt, profileraren för långsamma frågor och svar från explain() i det format MongoDB:s dokumentation beskriver. FerretDB:s explain() visar i stället PostgreSQL:s plan.
Prestanda
Samma prestandatest, tre gånger på var och en, en databas i taget medan den andra var i vila. Siffrorna är medianen av de tre körningarna. Varje anrop gick över TLS genom Podmans portvidarebefordran, som i guiderna, vilket lägger till omkring en millisekund på vart och ett.
| Arbete | FerretDB 2.7.0 | MongoDB 9.0.2 |
|---|---|---|
| Lägga in 100 000 ordrar i omgångar om 1 000 | 5,4 s (18 500 per sekund) | 4,6 s (21 800 per sekund) |
| Lägga in 5 000 ordrar en i taget | 18 s (270 per sekund) | 22 s (230 per sekund) |
| Skapa två index | 2,0 s | 1,2 s |
| 10 000 sökningar med index, 10 ordrar var | 41 s (250 per sekund) | 15 s (680 per sekund) |
Aggregering ($match, $unwind, $group, $sort), 10 gånger | 3,6 s | 2,0 s |
Join med $lookup av 2 000 ordrar, 10 gånger | 0,9 s | 0,9 s |
| 20 000 anrop, hälften ändringar och hälften läsningar, 1 klient | 77 s (260 per sekund) | 54 s (370 per sekund) |
| Samma med 8 klienter samtidigt | 29 s (695 per sekund) | 29 s (690 per sekund) |
update_many på en fjärdedel av ordrarna | 5,8 s | 1,3 s |
Enskilda skrivningar väntade på disken i båda, och varierade mellan körningarna: blandningen med en klient gick i 147 till 396 anrop per sekund i MongoDB och 223 till 283 i FerretDB. Läsningarna var jämnare. En sökning på _id tog 1,3 ms i MongoDB och 2,3 ms i FerretDB, och en ping 0,9 ms och 1,8 ms: FerretDB översätter varje kommando till SQL först. Vi kontrollerade att FerretDB använde indexet för sökningarna. Det gjorde den, den var bara långsammare per fråga.
Båda gav samma svar. Med den här mängden data handlar skillnaderna om millisekunder per anrop; med många läsningar per sida, eller stora ändringar, blir de märkbara.
Resurser
FerretDB använde mindre minne i vila, omkring 95 MB mot 210 MB, och FerretDB själv bara 7 till 10 MB: arbetet görs av PostgreSQL. MongoDB:s cache, WiredTiger, börjar större. Båda håller sig väl inom 8 GB, och båda går bra bredvid andra appar.
MongoDB sparade samma dokument på en tredjedel av utrymmet, eftersom WiredTiger komprimerar samlingar och index. FerretDB:s samlingar och index tog 71 MB, MongoDB:s 25 MB. Med så här lite data betyder loggarna mer för disken än själva datan, som tabellen visar.
FerretDB behöver nästan tre gånger så mycket disk för avbilderna, 2,87 GB med verktygen mot 1,09 GB.
Uppdateringar och säkerhetskopior
MongoDB-guiden följer taggen 9.0, och podman auto-update installerar varje version av 9.0 av sig själv. En ny huvudversion uppdaterar du för hand, en version i taget, och du slår på dess funktioner efteråt med setFeatureCompatibilityVersion, så att du kan gå tillbaka fram till dess.
FerretDB-guiden låser båda avbilderna, eftersom varje uppdatering görs för hand: nya taggar för FerretDB och PostgreSQL, en omstart och ALTER EXTENSION documentdb UPDATE i PostgreSQL. När vi tittade på FerretDB:s sida på GitHub den 14 oktober 2026 var den senaste versionen fortfarande 2.7.0, från november 2025, och den senaste ändringen i koden var från februari 2026. Tillägget DocumentDB hade gått vidare, till 0.117 och testversioner av 1.0, men FerretDB:s avbild har 0.107. Håll koll på projektet innan du förlitar dig på det.
MongoDB:s säkerhetskopia är en mongodump med oploggen, en kopia av ett enda ögonblick, på 2,5 sekunder här. FerretDB-guiden säkerhetskopierar på två sätt, en mongodump och en kopia av PostgreSQL:s data, på 9 sekunder. Varje återställning vi provade kom tillbaka med alla 105 000 ordrar och deras index, och appens inloggning fungerade efteråt.
Att flytta mellan dem går bättre åt ena hållet. FerretDB:s dump gick att återställa i MongoDB med alla index. MongoDB:s dump gick att återställa i FerretDB med alla dokument, men mongorestore stannade vid indexen med createIndex.collation is not implemented yet, så bara _id hade ett index. Att flytta från MongoDB till FerretDB betyder att du skapar indexen igen för hand, vilket vi inte testade.
Licens och kostnad
Vi kontrollerade projektens egna sidor och källkod den 14 oktober 2026.
- FerretDB är öppen källkod under licensen Apache 2.0 och görs av FerretDB Inc. Den körs på PostgreSQL, under PostgreSQL-licensen, och tillägget DocumentDB, under MIT-licensen, som Microsoft startade och som nu utvecklas i det egna projektet
documentdbpå GitHub. Du får köra den, ändra den och erbjuda den som tjänst åt andra. FerretDB:s dokumentation nämner ingen betald version, bara hjälp från andra användare på Slack och GitHub och ett kontaktformulär. - MongoDB Community Server har licensen Server Side Public License (SSPL) version 1, som MongoDB, Inc. skrev 2018. Open Source Initiative har inte godkänt den som öppen källkod. Du får köra den för dina egna appar, även kommersiella, och ändra den. Erbjuder du MongoDB självt som en tjänst åt andra måste du publicera källkoden till allt du använder för att driva tjänsten. Drivrutinerna,
mongoshoch databasverktygen har licensen Apache 2.0. MongoDB säljer Enterprise Advanced, med bland annat inloggning via LDAP och Kerberos och granskningsloggar, och sin molntjänst Atlas. Vi kontrollerade inte priserna.
Båda är gratis att köra på din egen server. MongoDB är ett varumärke som tillhör MongoDB, Inc., och FerretDB är inte MongoDB.
Vilken ska du välja
FerretDB passar en app som sparar och slår upp dokument, där licens med öppen källkod är viktig för dig eller dina kunder, eller där du redan kan PostgreSQL. Dess svagheter är allvarliga: transaktioner, vyer, collation och validatorer godtas och ignoreras, det finns inga behörigheter per inloggning, den var långsammare i de flesta av våra tester, och projektet hade inte gett ut något på elva månader när vi tittade. Kör appens egna tester mot den innan du flyttar. Följ FerretDB-guiden. Den går gott och väl på en VC-P Alloy.
MongoDB passar allt som bygger på transaktioner, change streams, schemavalidering eller en inloggning per app, och de flesta appar som är skrivna för MongoDB, som kan använda de funktionerna utan att säga det. Dess svagheter är SSPL, som inte är öppen källkod och begränsar att erbjuda den som tjänst, mer minne och en större journal från början, och ett replica set som ska sättas upp även med en enda server. Följ MongoDB-guiden, på en VC-P Alloy.
Tillsammans använde de under 800 MB med testdatan, så en VC-P Alloy kan också köra båda, som på vår testserver.