MongoDB
MongoDB is the most widely used NoSQL database, storing data as JSON-like BSON documents rather than rows and columns. Its flexible schema, horizontal scaling architecture, and rich query language make it well-suited for applications with evolving data models, hierarchical or nested data structures, and high-write workloads. MongoDB Atlas provides a fully managed cloud deployment with built-in replication, backups, monitoring, and global clusters.
Axevate uses MongoDB across SaaS applications, AI backends (for storing conversation history, vector embeddings via Atlas Vector Search, and agent state), and content-heavy applications. Our experience includes schema design for production workloads, aggregation pipeline optimization, Atlas configuration, and the operational concerns that determine whether a MongoDB deployment performs well or becomes a maintenance problem.
1Document Model and Schema Design
MongoDB's flexible schema - no required schema definition, no migration scripts for adding fields - accelerates development but creates long-term maintenance risks if not managed deliberately. Production applications should define schemas explicitly using Mongoose (Node.js ODM) or Motor (Python async driver), not to enforce rigid structure but to document expected shapes, validate incoming data, and prevent subtle bugs from unexpected field names or types.
The core schema design decision is embedding vs. referencing. Embed related data (store address embedded in a user document) when data is always accessed together, has a bounded size, and won't be queried independently. Reference related data (store orders as a separate collection with a user ID reference) when data grows unboundedly, needs to be queried independently, or is shared across multiple parent documents. MongoDB's aggregation $lookup enables JOIN-like queries across collections, but performance is far better when you can retrieve what you need in a single document read.
Indexes are the most impactful performance lever after schema design. Every query that runs in production should have a supporting index. The Explain Plan (db.collection.explain('executionStats').find(...)) shows whether a query is using an index (IXSCAN) or scanning the collection (COLLSCAN). A single COLLSCAN on a large collection can cause response times to spike from 2ms to 2000ms as the collection grows.
2Aggregation Pipelines
MongoDB's Aggregation Framework is the primary tool for complex data transformations, analytics queries, and reporting. A pipeline is an array of stages - $match (filter), $group (aggregate), $sort, $project (reshape), $lookup (join), $unwind (flatten arrays), $facet (multiple aggregations in parallel). Aggregations can replace application-layer processing with database-layer processing, dramatically improving performance for analytics workloads.
Aggregation pipeline performance depends heavily on stage ordering. Place $match stages as early as possible to reduce the documents flowing through subsequent stages. Index usage in aggregations is governed by the same rules as find queries - the first $match stage can use an index; stages later in the pipeline generally cannot. Use $project early to strip fields you don't need, reducing the document size flowing through the pipeline.
3Atlas Vector Search
MongoDB Atlas Vector Search enables semantic search and RAG directly within your existing MongoDB database, eliminating the need for a separate vector database. You store vector embeddings as fields in documents and query by similarity using the $vectorSearch aggregation stage. This is useful for AI applications that need to store both structured data and embeddings in the same place - conversation history with associated embeddings for retrieval, product catalogs with semantic search, or knowledge bases for RAG.
Atlas Vector Search supports HNSW (Hierarchical Navigable Small World) indexing for approximate nearest neighbor search at scale. It works with any embedding model and integrates with LangChain's MongoDBAtlasVectorSearch retriever. For teams already on MongoDB Atlas, it's worth evaluating as the vector storage layer before introducing Pinecone or Weaviate - fewer infrastructure components to manage.
How We Use It in Practice
Real architectural problems across industries — and how we approach them.
MongoDB Atlas Vector Search + LangChain: Conversation Memory for a Multi-Tenant AI Assistant
A SaaS platform providing AI assistants to 300+ business clients needed each client's conversation history to be semantically searchable for long-term memory — users could reference 'that campaign we discussed last month' and the assistant needed to retrieve relevant prior context. Each client's data had to be completely isolated. A dedicated vector database (Pinecone) was considered but would have meant a separate index per tenant, complex provisioning, and a second data store to maintain.
Our approach
MongoDB Atlas Vector Search with Atlas Search indexes. Each conversation turn is stored as a document with a tenant_id field, message content, and an embedding vector (OpenAI text-embedding-3-small, 1536 dimensions). Atlas Search index with a knnVector type on the embedding field. At query time, the LangChain MongoDBAtlasVectorSearch retriever runs a $vectorSearch aggregation with a pre-filter on tenant_id — enforcing isolation at the database query level rather than the application layer. Top-5 semantically similar prior turns are injected into the system prompt as long-term memory context. The solution eliminated a separate vector database, kept all customer data in one MongoDB Atlas cluster under existing backup and compliance controls, and reduced memory retrieval latency to under 80ms.
Schema Migration Without Downtime: Renaming 40M Documents Across a Live Collection
A content platform needed to rename a field from author_id to created_by_user_id across a 40-million-document articles collection in MongoDB — the old name was ambiguous in a new multi-author context. The collection received 500 writes/minute around the clock with no maintenance window available. A naive db.articles.updateMany({}) would lock the collection and potentially run for hours. Application code needed to handle both field names during the transition.
Our approach
Dual-read/dual-write migration pattern: deployed application version N+1 that writes both author_id and created_by_user_id on every write, and reads from created_by_user_id with fallback to author_id. This decoupled the application deployment from the data migration. A background migration script (running as a scheduled job) used cursor-based batching — processing 1,000 documents per batch, sleeping 100ms between batches, and tracking progress via a migrations status collection. The $set + $unset migration ran over 72 hours without impacting production write throughput. Once 100% of documents had created_by_user_id populated (verified by a count query), application version N+2 removed the fallback read and the author_id writes. Zero downtime, zero errors in application logs during the transition.
Aggregation Pre-Computation: Replacing Slow Analytics Queries with a Summary Collection
A marketplace platform ran daily seller performance reports using a MongoDB aggregation pipeline across an orders collection that had grown to 85 million documents. The analytics aggregation (grouping by seller, calculating GMV, return rates, and rating distributions across date ranges) was taking 4-8 minutes to complete and consuming enough database resources to degrade production query performance during the run. It was running during off-peak hours but the window was shrinking as the dataset grew.
Our approach
Pre-computation strategy: a daily Atlas Scheduled Trigger runs a lighter aggregation that processes only the previous day's orders (5,000-15,000 documents vs. 85 million) and upserts results into a seller_performance_daily summary collection. The reporting queries now run against the pre-aggregated summary collection — from 4-8 minutes to under 200ms, regardless of total order history size. For ad-hoc date range queries beyond what the daily summary covers, a separate monthly rollup collection handles quarter and year-to-date calculations. The production collection is never touched by analytics queries during business hours. The Scheduled Trigger approach also gave the team a natural place to add data quality checks and send alerts if daily order counts deviated significantly from the expected range.
FAQ
MongoDB is well-suited for: flexible or evolving schemas, hierarchical/nested data (documents, configurations, content), high-write workloads, and applications where horizontal sharding may be needed. PostgreSQL is better for: complex relational data with many JOINs, strong consistency and transaction requirements, financial or compliance workloads requiring ACID guarantees, and analytics with complex SQL queries. Many modern applications use both - MongoDB for operational data, PostgreSQL for transactional data.
For most production applications, Atlas is worth it. The managed replication, automated backups, monitoring, and Atlas Search capabilities eliminate significant operational overhead. Self-hosted MongoDB requires managing replica sets, backup procedures, monitoring setup, and security configuration - work that Atlas handles automatically. The breakeven depends on your team's infrastructure capacity and the value of engineering time.
Use connection caching: define your Mongoose or MongoClient connection outside the handler function, check if a connection already exists before creating a new one, and reuse the cached connection. This pattern works with Next.js, Vercel Functions, and AWS Lambda. MongoDB also offers the Atlas Data API for serverless environments that need HTTP-based database access without persistent connections.
Yes - MongoDB Atlas Vector Search stores and queries vector embeddings directly in your Atlas cluster. It integrates with LangChain, supports HNSW approximate nearest neighbor search, and allows you to combine semantic search with structured MongoDB queries in a single aggregation pipeline. For teams already on Atlas, this eliminates the need for a separate Pinecone or Weaviate instance for straightforward RAG use cases.