How to get started with the FerretDB 2.0 surge

FerretDB 2.0 moves away from the lightweight SQLite backend that users preferred for small, local, or embedded applications. The developers removed SQLite support because they lack the financial support or code contributions to maintain it. They view 1.x and 2.x as two different products for different purposes, prioritizing performance and compatibility in the new version. This decision changes the profile of the tool from an embeddable, low-RAM option to a server-based solution. A typical SQLite setup for FerreDB used between 20 and 30 MB of RAM. In contrast, a PostgreSQL backend uses at least five to seven times that amount. Can the community provide enough financial support to bring the SQLite backend back to the roadmap?

Technical realities and feature gaps

I find that the technical differences between MongoDB and FerretDB are most visible after the query leaves your process. FerretDB acts as a stateless proxy that implements the MongoDB wire protocol on top of PostgreSQL. You can use the same mongodb driver and the same mongodb:// connection string you use today. The application code remains identical because FerretDB handles the translation to SQL.

FerretDB does not support all MongoDB features. It lacks support for $lookup, $graphLookup, change streams, capped collections, and schema validation. It also misses the $merge or $out aggregation stages. If you rely on Atlas Search or the wider Atlas ecosystem, you should stay on MongoDB. FerretDB also has data type restrictions. It does not support NUL characters in strings or nested arrays. Document keys cannot start with the $ sign or contain a period. Database names must not include non-latin letters. FerretDB also converts -0 to 0.

MongoDB uses WiredTiger, a purpose-built engine optimized for document workloads using B-trees and log-structured merge trees. This design favors high write throughput and large working sets. MongoDB scales horizontally through native sharding, while PostgreSQL requires tools like Citus or manual sharding for similar needs. FerretDB stores documents as JSONB in PostgreSQL tables. Because FerretDB stores documents as JSONB in PostgreSQL tables, your data benefits from battle-tested storage, write-ahead log crash recovery, and autovacuum maintenance that your team already manages.

Decision logic for migrations

You probably already know that MongoDB’s popularity comes from its flexible schema and easy drivers. I would skip FerretDB if your project requires heavy use of the aggregation pipeline or real-time change notifications. However, FerretDB is a strong choice if you want to avoid the SSPL license. The Apache 2.0 license allows you to host the database as a service without open-sourcing your entire stack.

For teams migrating away from MongoDB, the process involves swapping the connection string and running your test suite. You can use the MongoDB Atlas migration page to copy collections and documents into a managed FerretDB database on Layerbase Cloud. FerretDB on Layerbase Cloud provides point-in-time restores because it archives the PostgreSQL write-ahead log. This allows you to restore to any timestamp that the archive covers. You can also use the Layerbase CLI to run both MongoDB and FerretDB side by side without manual configuration. The migration tool reads the source once and never modifies it, which allows you to verify document counts against the source to ensure accuracy.

For e-commerce use cases, denormalized data is a boon. You can perform a single read of a product to show all its information instead of joining many tables. FerretDB allows this document-based approach on PostgreSQL infrastructure. For prototyping, you can start with the MongoDB API and later move to structured PostgreSQL tables. If your data is naturally document-shaped, stay with MongoDB. If you want your document data to live alongside relational data, use FerretDB.