About the Project
The idea for this project came from my experience during my internship. I noticed that when people needed to analyze data stored in MongoDB, they often preferred to move that data into another database first because they were more comfortable with SQL. In some cases, people would even avoid using MongoDB entirely because they did not want to lose access to the SQL ecosystem they already relied on.
That made me ask:
What if developers could keep using MongoDB, while still working with the SQL tools they already know?
My first attempt was to build a FastAPI-based service that sat in front of MongoDB. The service handled schema discovery across collections and translated SQL queries into MongoDB operations.
Simple queries were converted into MongoDB find() operations, while more complex queries used aggregation pipelines with stages like $lookup, $unwind, and $group to support operations such as joins and grouping.
The entire system was containerized with Docker and exposed through a REST API for schema discovery and query execution.
However, after researching the existing landscape, I realized the problem was not simply "SQL support for MongoDB." That space already had several solutions, including MongoDB's own SQL interface and other third-party tools. Most of these solutions focused primarily on analytics and querying, and were generally read-only.
The more interesting gap was:
Write support through standard SQL tools.
Existing approaches that supported writes were either difficult to install, incomplete, or lacked the reliability expected from production tooling.
This shifted the direction of the project. Instead of building another SQL query layer for MongoDB, I focused on creating a PostgreSQL-wire compatible proxy that allows existing PostgreSQL clients to connect directly to MongoDB and perform both reads and writes.
The final project was built around this idea:
Make MongoDB accessible through the tools developers already understand, without requiring data migration or replacing the database.
Through building this project, I learned that identifying the real problem is often harder than implementing the first solution. The initial idea was technically interesting, but research helped narrow the focus toward a more meaningful gap.
The biggest challenges were mapping SQL concepts to MongoDB's document model, handling nested documents correctly, dealing with schema flexibility and mixed data types, and ensuring that SQL operations could translate into predictable MongoDB updates.
The result is a prototype that demonstrates how a PostgreSQL-compatible interface can bridge the gap between relational tooling and document databases, allowing developers to use familiar SQL workflows while keeping MongoDB as the underlying data store.
Log in or sign up for Devpost to join the conversation.