Management Pain: When Infrastructure Bloat Hits Due to Too Many Databases
Imagine your project is running smoothly on PostgreSQL for complex financial transactions. Suddenly, the team needs an additional flexible storage module for logs or metadata, and MongoDB is brought in. The result? You now have to operate, monitor, and back up two different database management systems (DBMS) just to serve a few minor needs.
Running these two giants side-by-side consumes at least 2-4GB of RAM for minimum instances. For DevOps engineers, this is a nightmare—doubling security protocols, permission management, and backup strategies. Not to mention, MongoDB’s move to the SSPL license makes long-term costs and freedom a major headache.
Why is it so Hard to Let Go of MongoDB?
Why not just use Postgres’s jsonb from the start? The answer lies in the MongoDB Driver. Code logic is tightly coupled with NoSQL syntax; converting to pure SQL is like “heart surgery” for an application—extremely time-consuming and risky.
Removing MongoDB means refactoring thousands of lines of code. Meanwhile, although PostgreSQL handles JSON very well, it cannot communicate using the wire protocol that MongoDB applications understand. We need a “translator” that can convert Mongo commands into SQL in an instant.
3 Common Paths for Developers
To escape this situation, most of us usually choose one of three paths:
- Accepting reality: Continue running both in parallel. This is safe but consumes a massive amount of server RAM and CPU.
- Full rewrite: Tear down and rebuild the logic using Postgres’s
jsonb. This is the cleanest way but costs weeks or even months of labor. - Deploying FerretDB: A middle-ground but highly effective solution. You keep your old code, continue using the MongoDB Driver, but the actual data lives in PostgreSQL.
FerretDB: When PostgreSQL “Impersonates” MongoDB
FerretDB (formerly MangoDB) is an open-source project (Apache 2.0) that acts as a Proxy layer. It doesn’t store data itself; it simply translates MongoDB queries into PostgreSQL SQL.
FerretDB is essentially the bridge that lets you leverage document-oriented database flexibility on the rock-solid foundation of Postgres. You get total ACID reliability without losing the joy of flexible JSON manipulation.
Superfast FerretDB Setup with Docker Compose
To test this out, I’ll set up a cluster with PostgreSQL 16 and FerretDB acting as the front-end. It takes about 2 minutes to get the system ready.
version: '3.8'
services:
# Main database backend
postgres:
image: postgres:16
container_name: postgres
environment:
POSTGRES_USER: ferretuser
POSTGRES_PASSWORD: secretpassword
POSTGRES_DB: ferretdb
ports:
- "5432:5432"
# FerretDB Proxy
ferretdb:
image: ghcr.io/ferretdb/ferretdb:latest
container_name: ferretdb
restart: always
environment:
FERRETDB_POSTGRESQL_URL: "postgres://ferretuser:secretpassword@postgres:5432/ferretdb"
ports:
- "27017:27017" # Standard MongoDB port
depends_on:
- postgres
Once the docker-compose.yml file is ready, just run the command to activate it:
docker-compose up -dVerifying the Connection with mongosh
Real-world testing with the legendary mongosh tool. You’ll see everything works exactly like connecting to a real MongoDB instance:
mongosh "mongodb://127.0.0.1:27017/"Try adding a record to a collection:
db.itfromzero.insertOne({
name: "FerretDB Tutorial",
type: "Database Proxy",
save_cost: "50% RAM"
});
db.itfromzero.find().pretty();
Here’s the secret: When you check the PostgreSQL database using pgAdmin, you’ll see that FerretDB has automatically created tables and populated the jsonb column. Everything happens completely automatically and transparently.
Pitfalls to Watch Out For Before Going to Production
While convenient, FerretDB isn’t a silver bullet for every case. You should carefully examine these 3 points before migrating:
- Compatibility: Currently supports Wire Protocol 5.0+, but complex Aggregation operators might not be 100% yet. Check their roadmap regularly.
- Performance: Adding a proxy layer inevitably introduces slight latency. For typical CRUD apps, this isn’t an issue, but high-traffic apps require thorough benchmarking.
- Index Management: FerretDB maps indexes automatically, but they might not be as optimized as manual Postgres indexing. Don’t forget to monitor Slow Queries on the Postgres side.
In short, if you want to simplify your infrastructure, consolidate all your data in one place for easier management, and avoid touching legacy code, FerretDB is an excellent choice. It frees you from the burden of operating unnecessary, bulky DB clusters.
