The Current State of MongoDB Alternatives, and Two Years of FerretDB.
blank

DDC

Reading Time: 9 minutes

How about more insights? Check out the video on this topic.

blank

Modern businesses are increasingly demanding agile and scalable database solutions to keep pace with their growth. This has led to the rising popularity of document databases like MongoDB. However, FerretDB is staking its claim as a robust competitor in this space.

FerretDB was founded by Peter Farkas and Alexey Palazhchenko, who are veterans in the database industry. They realized the need for an alternative to MongoDB due to concerns over vendor lock-in and limited compatibility options. FerretDB aims to provide users with more choice and the ability to seamlessly transition from MongoDB without major disruptions.

In this webinar founders discuss a vision of creating a standardized alternative to MongoDB, similar to how SQL became an open standard for relational databases. By building FerretDB on top of PostgreSQL, an open-source database, they ensure stability, extensive community support, and existing JSON compatibility capabilities.

Highlights:

  • The document database market is in need of alternatives and open standards.
  • FerretDB is an open-source MongoDB alternative that is compatible with MongoDB drivers.
  • FerretDB was built on top of PostgreSQL for database storage and compatibility.
  • The roadmap for Ferret DB includes expanding feature compatibility with MongoDB and other frameworks.
  • FerretDB is working on becoming an open standard and offering a database-as-a-service option.

Peter Farkas: 

Hi there! Welcome to the latest presentation of our Document Database Series. This webinar is a bit different from what we usually do, and we’ll explain why in a bit. For those new to the series, we’ve been running it for nearly a year now, covering various aspects of document databases and the broader tech landscape.

Alexey Palazhchenko

That’s right, Peter. I’m Alexey Palazhchenko Palazhchenko, co-founder of FerretDB. While I’ve worked on various projects like Teleconomy International Management and the Dallas project at a Linux-based cloud company, my passion for databases and open source led me here.

Peter Farkas: 

I’m Peter Farkas, CEO, and co-founder of FerretDB. With over 15 years in the database world, I’m deeply committed to open source and how it connects with databases.

Alexey Palazhchenko

Our paths didn’t cross at Percona, but it was Peter Zaitsev, our third co-founder and former CEO of Percona, who introduced us. His open source and database expertise has greatly influenced FerretDB’s direction.

MongoDB Popularity

Peter Farkas: 

So why did we create FerretDB, and what problem were we addressing? Well, this chart from the Stack Exchange developer survey of 2022 shows MongoDB as the fourth most popular database developers want to engage with. But MongoDB has strayed from open source principles by shifting to a more restrictive license.

Alexey Palazhchenko

MongoDB’s recent license changes are concerning. They shifted from AGPL version 3 to a custom license, the Server Side Public License (SSPL). It raises issues around the definition of “making functionality available as a cloud service” and what’s considered part of the “server source code.”

Peter Farkas: 

The SSPL has sparked debates and isn’t universally accepted as open source. It’s also raised questions about whether MongoDB, Inc. might breach the copyright of the SSPL license text itself.

Alexey Palazhchenko

True, and while some may think SSPL compliance is straightforward, many companies with legal teams are cautious due to its ambiguity.

 

License

Alexey Palazhchenko

So, Peter, one major risk with MongoDB’s new SSPL license is the limited options for service providers. They’re left with the choice to either pay MongoDB, Inc. for a commercial license or use an outdated version of MongoDB, which lacks security updates and modern features?

Peter Farkas: 

Exactly, and this isn’t ideal for many small businesses since MongoDB relies heavily on cloud providers for revenue.

Alexey Palazhchenko: 

Right. Cloud providers, just like any business, want to offer alternatives to their customers, but the SSPL restricts them. They can’t simply offer the latest MongoDB version; they’d have to develop their own solution or collaborate with us.

Peter Farkas: 

So, for instance, if I were a service provider wanting to offer MongoDB as a service, the SSPL would prevent me from doing so.

Alexey Palazhchenko: 

Yes, unless you’re using an old, unsupported version. This situation essentially reduces choices for end-users, creating a sort of vendor lock-in. If MongoDB’s stock price drops, they can raise prices, and users would have no alternatives.

Peter Farkas: 

True. While MongoDB might want to maximize profits, it’s better for users to have multiple vendors to choose from based on pricing, features, support, and more. Having several vendors in one space usually benefits the customer.

Alexey Palazhchenko: 

So, at first glance, SSPL might seem bad for service providers, but in the end, it limits choices for users seeking MongoDB solutions.

Peter Farkas: 

Right, and this limitation of choices brings us to the question of why there’s such a difference between relational databases and document databases like MongoDB. To explore this, let’s delve into the history of SQL.

SQL
History of SQL

Alexey Palazhchenko: 

SQL’s history is fascinating. It started with IBM’s Edgar Codd introducing the concept of relational databases, but the initial query language was complex, more like writing separate programs to extract data.

Peter Farkas: 

That’s right. It was Don Chamberlain and Ray Boyce, also at IBM, who developed the foundations of SQL in the early ’70s to make relational databases more user-friendly.

Alexey Palazhchenko: 

Tragically, Ray Boyce passed away shortly after their groundbreaking work, and he never got to witness the impact SQL had on the database world.

Peter Farkas: 

IBM released relational database products, notably IBM DB2, which required their hardware, essentially creating vendor lock-in. This was common for such groundbreaking inventions.

Alexey Palazhchenko: 

Other vendors saw the success of relational databases and began implementing SQL in their products, leading to various SQL dialects and implementations that weren’t compatible with each other.

Peter Farkas: 

So, looking back at the history of SQL and how it evolved from complex beginnings to an open standard, we can see that initially, vendors like IBM created relational databases with their own proprietary query languages, creating vendor lock-in. Each vendor had its own unique approach, making it challenging for applications to work with different databases.

Alexey Palazhchenko:

Exactly. The goal was to simplify database usage for end-users, but each vendor wanted to keep users within their ecosystem. This led to dozens of incompatible implementations. However, the big shift happened when SQL became an industry and ISO standard, providing a reference paper outlining its core functionality.

Peter Farkas: 

Right, and even though there are still dialects of SQL, they are much more similar than the diverse approaches of the ’70s and ’80s. The standardization allowed for hundreds of successful SQL derivatives and created a relatively democratic landscape for relational databases.

SQL open standard

Alexey Palazhchenko: 

Now, when we look at MongoDB, it started with a promise of simplicity, allowing developers to work with objects in their favorite language without dealing with complex schema and relationships. Initially open source, it gained popularity rapidly, but then MongoDB, Inc. changed the license to SSPL, making it proprietary.

Peter Farkas: 

Yes, the introduction of SSPL essentially puts MongoDB in a similar situation to those early relational database vendors, dictating the query language format. This means that everyone else has to follow MongoDB’s lead.

Alexey Palazhchenko: 

While there are some partial solutions that implement SQL for MongoDB, they all vary and lack true compatibility. Switching between them isn’t straightforward, as they support different features, making it challenging for users.

Peter Farkas: 

But what if we could create an open standard for MongoDB’s query language or leverage something like GraphQL, which is already open and documented? This could allow for the standardization of a JSON query language, enhancing portability between MongoDB-compatible backends.

Alexey Palazhchenko: 

That sounds promising. If extensions or features are added to the query language, they could be standardized, ensuring compatibility between products. Multiple competition vendors working together on this would be beneficial for users.

Peter Farkas: 

Unfortunately, we’re currently facing a situation where a single vendor controls everything, from the framework to applications and tools, creating a similar scenario to the one we saw in the history of SQL.

Peter Farkas: 

Looking at the situation now, it’s somewhat reminiscent of the 1980s, where various proprietary solutions attempted to replicate MongoDB’s behavior. But is this sustainable? Can the industry continue creating alternatives to MongoDB just to foster innovation and avoid vendor lock-in?

Alexey Palazhchenko: 

That’s a good question. MongoDB compatibility aims to leverage existing elements of the MongoDB ecosystem, so developers don’t have to relearn everything. It’s about reusing frameworks and tools, making the transition seamless.

MongoDB alternatives
The issue with MongoDB alternatives

Peter Farkas: 

Right. There are various MongoDB alternatives out there, including FerretDB, DocumentDB, and others. These alternatives aim to be MongoDB-compatible, but they have different feature sets and levels of compatibility. MongoDB sets the pace, and alternatives follow suit.

Alexey Palazhchenko: 

Exactly. MongoDB compatibility is about allowing users to connect with the same tools, frameworks, and UI applications they’re already familiar with, even if they switch to an alternative like FerretDB. However, due to differences between products, full compatibility isn’t always guaranteed.

Starting with FerretDB

Peter Farkas: 

When we reflect on why we started FerretDB, it’s because we saw the risks associated with a single vendor and a lack of compatibility among alternatives. We want to emulate the success of SQL by creating an open-source alternative, standardizing it, and allowing users to have more choices and flexibility.

Alexey Palazhchenko: 

That’s right. We launched FerretDB as “MangoDB” on GitHub in November, and the response was overwhelming, with thousands of stars and interest from large enterprise companies. Our aim was to create an open-source alternative to MongoDB, using Apache 2.0 licensing, and it’s based on PostgreSQL to ensure compatibility.

Peter Farkas: 

The architecture of FerretDB allows you to take any application that uses MongoDB and swap it for FerretDB without changing much. We use MongoDB drivers because they’re already available and are under the Apache 2.0 license. Our goal is to make the transition as seamless as possible for developers.

Alexey Palazhchenko: 

And we chose PostgreSQL as the foundation because it’s free and open-source, similar to FerretDB. It’s also highly regarded in the community and has extensive support.

Peter Farkas: 

You know, Alexey, our journey with FerretDB began with a fundamental question: why do users have to rely on a single vendor like MongoDB with its proprietary licensing model when there are alternatives that can offer more freedom and compatibility?

FerretDB licensing

Alexey Palazhchenko: 

That’s true, Peter. We recognized the need for a MongoDB alternative that was open source and could reduce the risks associated with vendor lock-in. That’s what set us on this path to create FerretDB.

Peter Farkas: 

Absolutely. In today’s digital landscape, businesses need agility and scalability. MongoDB has been a popular choice, but we saw the opportunity to provide a more standardized and compatible solution. We wanted FerretDB to become a benchmark in the document database market, similar to how SQL has been in the relational database world.

Alexey Palazhchenko: 

One of the core principles of FerretDB is vendor-independence. We believe in a user-centric database industry. MongoDB’s proprietary licensing has led to limited service providers and options, and that’s where FerretDB comes in. We aim to be a viable alternative to MongoDB without disrupting the user experience.

Peter Farkas: 

Right, and our architectural approach is quite innovative. By building FerretDB on the strong foundations of PostgreSQL, an open-source database, and cleverly leveraging MongoDB drivers, we ensure seamless compatibility. MongoDB users can transition to FerretDB without the need for extensive code changes or learning new frameworks.

Postgres derivatives

Alexey Palazhchenko: 

And let’s not forget our unique selling proposition – out-of-the-box compatibility. FerretDB seamlessly integrates into existing frameworks and software, making it an easy switch from MongoDB. We’ve been actively working on compatibility with popular frameworks like the Meteor Stack to cater to a broader user base.

Peter Farkas: 

What’s exciting is our growing community. FerretDB is a community-driven project, with a robust customer base and active development contributions. User feedback and testing are at the core of our continuous improvement efforts.

Alexey Palazhchenko: 

Looking ahead, FerretDB’s future looks promising. Our roadmap is publicly available on GitHub, and while we’re production-ready, we understand that suitability varies based on specific use cases. We’re even exploring partnerships to offer FerretDB as a service while advocating for open standards in the MongoDB Query Language (MQL).

Peter Farkas: 

Indeed, the dynamic FerretDB team actively seeks user feedback through our Slack group and GitHub. As the database industry continues to evolve, FerretDB is on a compelling journey, offering an open-source, community-driven alternative to MongoDB, eliminating vendor lock-in concerns, and pushing for standardized document databases.

Alexey Palazhchenko: 

Whether you’re an experienced developer or an enterprise seeking flexible and compatible database solutions, FerretDB is here to provide a user-centric, vendor-independent experience in the ever-expanding world of databases.

If you want to learn more about FerretDB and stay updated with its latest developments, check out the recorded webinar on YouTube. Don’t miss out on upcoming webinars and events where you can delve deeper into related topics like SSPL (Server Side Public License).

0 Comments

Related posts

Subscribe to Updates

Privacy Policy