MongoDB Atlas (pay-as-you-go)

What do you like best about the product?

We love the “no schema” aspect of MongoDB for our development process. We are able to iterate quickly instead of having to perform complex migrations and even downtime as in traditional relational databases when we need to change our schema just a little. Our full stack environment with JavaScript makes it very natural for our engineers to store data in JSON-like documents. The aggregation framework is extremely powerful: you can do a lot of complex data transformations and analytics directly in the database – even without having to do a lot of heavy processing elsewhere. Plus, horizontal scaling (sharding) and seamless replica sets setup provides us with a great amount of confidence for HA and scaling up in the future.

What do you dislike about the product?

The biggest advantage here is flexibility, but that can also become the biggest drawback if the team isn’t disciplined. Without application-level validation or strong data modeling, the database can quickly turn into a data dump, which makes it much harder to maintain over time. Memory management can also be quite aggressive: Mongo loves RAM, and if your collections aren’t indexed properly, performance can drop significantly, driving up infrastructure costs. Finally, while it’s much better at handling complex relationships than it used to be, highly relational data with heavy nesting can still lead to huge documents and overly complicated aggregation pipelines, which are a nightmare to debug.

What problems is the product solving and how is that benefiting you?

Our dynamic application data is heavily dependent on MongoDB, with complex user profiles, real-time activity feeds, a highly customizable content management dashboard. Prior to the adoption of MongoDB, we had an RDBMS in which users would add custom fields to their profiles, resulting in inefficiencies and implementing EAV, or Entity-Attribute-Value anti-patterns, or constantly changing tables.With MongoDB, the solution was to have each user document with a different structure, completely solving this issue. This change reduced the feature deployment time by 50%, as the database was no longer a bottleneck in sprints. We've also moved our audit logging system to MongoDB, using its ability to write a lot of data to change things, which helped us eliminate the performance lag that our users had been feeling at peak times.

What do you like best about the product?

It is how flexible the document-based structure is for handling real project data. I use it in Node.js backend projects where storing JSON-like data directly as documents makes development much faster compared to traditional relational databases. Adding new fields or updating schemas is simple, so I don’t have to redesign tables every time requirements change. The performance is also very good for read and write operations in smaller web applications and APIs. I’ve integrated it with Auth0 to manage user data after authentication and the workflow feels smooth. MongoDB Atlas onboarding was straightforward, and connecting databases to applications took only a few minutes. Overall, it helped me build and scale backend projects more quickly with less database management complexity.

What do you dislike about the product?

It is that managing complex relationships between data can become difficult compared to SQL databases. In one of my backend projects, handling deeply connected user and task data required extra queries and manual structuring. I also noticed that if indexes are not configured properly, query performance can slow down as the database grows. MongoDB Atlas is easy to start with, but pricing increases quickly when storage and usage scale up. Debugging aggregation pipelines can also become confusing for more advanced queries. Overall, it works great for flexible data structures but complex data handling and scaling need careful management.

What problems is the product solving and how is that benefiting you?

It solved my problem of handling flexible and changing data structures in backend projects. Earlier, whenever project requirements changed, modifying tables and schemas in relational databases took extra effort and slowed development. With MongoDB, I can store JSON-like documents directly, which makes it much easier to manage user data, project details, and API responses. In one of my Node.js projects, I integrated it with Auth0 to store authenticated user profiles without creating complex database tables. Querying and updating data became much faster during development. It also reduced the time needed for database setup and schema changes.

What do you like best about the product?

Mongodb is fine-tuned , performance supporting Database, feature liks Integration, Pricing and ROI,Schema Flexibility,High Scalability,Rich Query , Language, AI features

What do you dislike about the product?

TTL Indexes :Automatically delete old documents after a time period. Useful for logs/sessions, but not very exciting.
Replica Set Elections :Internal process for choosing a primary node during failover. Important for reliability, but mostly infrastructure mechanics.
Write Concerns: Controls how safely data is written across replicas. Critical in production, but configuration-heavy.
Capped Collections :Fixed-size collections that overwrite old data. Niche use case.
BSON Size Limits :Technical limitation discussions (16 MB document limit) are practical but not fun.

What problems is the product solving and how is that benefiting you?

It is solving scheme flexiblity and performance problem

What do you like best about the product?

Speed of iteration
flexibility
strict relational consistency

What do you dislike about the product?

no enforced schema
harder data governance

What problems is the product solving and how is that benefiting you?

problem- rigid schemas slow teams down
benefits- store flexible docs

What do you like best about the product?

What I like most about MongoDB is how much it speeds up real-world development without getting in the way.

From a daily workflow perspective, the document model is the biggest win. I store data in the same nested structure my APIs return, so I don’t spend time joining tables or reshaping responses. That alone cuts hours when building or modifying endpoints.

The aggregation pipeline is something I use regularly for dashboards and analytics. Instead of writing extra backend logic, I handle filtering, grouping, and transformations directly in the database, which keeps my codebase cleaner and faster.

On the UI/UX side, MongoDB Compass and Atlas make a difference. Being able to visually inspect documents, test queries, and manage indexes saves a lot of debugging time compared to purely CLI-based workflows.

Performance-wise, proper indexing (especially compound indexes) has significantly improved query speeds in my apps, often turning slow endpoints into near-instant responses.

An unexpected benefit has been how well it handles rapid product changes. I can ship features without locking into a strict schema early, which has made iteration much faster and reduced rework.

Overall, it’s improved my workflow by reducing boilerplate, simplifying data handling, and letting me move faster from idea to production.

What do you dislike about the product?

What I dislike about MongoDB mainly shows up as the project grows.

The biggest issue is schema inconsistency. Since validation isn’t strict by default, collections can end up with mixed document structures. This has caused bugs for me in production because different records don’t follow the same shape. I usually fix this with Mongoose or custom validation, but it adds extra complexity. Stronger, more opinionated schema enforcement out of the box would help.

Handling relationships is another weak spot. $lookup works, but it’s not as clean or performant as SQL joins for complex relations. In some cases, I’ve had to duplicate data or restructure things, which increases maintenance overhead. A more optimized and developer-friendly way to handle relations would improve this.

On the UI side, tools like Compass are useful, but they can feel slow or limited when working with large datasets. Querying and exploring big collections isn’t always smooth. Better performance and more advanced debugging tools would make a difference.

Pricing can also become a concern with MongoDB Atlas as usage scales. Costs increase quickly with storage and operations, which impacts ROI for smaller projects. More transparent cost optimization suggestions would help developers manage this better.

Overall, these issues don’t block usage, but they do add friction as the system scales.

What problems is the product solving and how is that benefiting you?

MongoDB mainly solves the problem of rigid data models slowing down development.

We struggled with frequent schema changes and migrations in relational databases, but now we can evolve document structures on the fly, which has resulted in much faster feature delivery.

We also struggled with complex joins and reshaping data for APIs, but now we can store related data together and fetch it in a single query, which has reduced backend complexity and improved response times.

In terms of impact:

Development time for new features reduced by ~30–40%
API response times improved (e.g., ~400ms → ~150ms in some endpoints)
Less time spent on migrations and schema refactoring

Overall, it’s made our workflow more flexible and significantly faster, especially in fast-changing products.