DEV Community: Priya Singh

SRE for People Who Hate SSH: A Beginner’s Guide to MongoDB Atlas

Priya Singh — Sat, 04 Jul 2026 06:57:36 +0000

Let’s be honest: very few people wake up in the morning, stretch their arms, and think, "Man, I cannot wait to write some custom automated backup cron jobs, manage TLS certificates, and manually configure database sharding today!"

If you do, congratulations, you are a rare breed of infrastructure wizard. The rest of us? We just want to write code, ship features, and build applications. We want to be application developers, not database plumbers.

In my last chapter of ScalingDiaries, we talked about the "Relational Hangover" and how shifting from strict tables to MongoDB’s flexible document model saved my sanity. But once you commit to MongoDB, you face an immediate structural choice. Where does this thing actually run?

Today, we are stripping away the complexity and going back to the basics: demystifying the deployment models, breaking down what MongoDB Atlas actually is, and exploring why migrating to a fully managed cloud database-as-a-service (DaaS) is the ultimate cheat code for developers who hate SSHing into servers at 3:00 AM.

The Three Flavors of MongoDB
Before we can appreciate the luxury of a fully managed cloud database, we have to understand the three primary ways MongoDB can exist in the wild:

1. MongoDB Community Server (The "Localhost" Special)
This is the free, open-source edition of MongoDB. It operates under the Server Side Public License (SSPL). Under the SSPL, you are completely free to download it, inspect the source, tweak it, and run it locally to your heart's content. You can download the MongoDB Compass GUI for free to query and visualize your data without typing commands in a terminal. The Catch: The SSPL dictates that you cannot use Community Server to run a commercial SaaS product where you serve MongoDB itself as a hosted service. And more importantly, you are entirely on your own. If your server dies, if your database gets corrupted, or if you need to scale horizontally—well, I hope you like reading stack traces on online forums.

2. MongoDB Enterprise Advanced (The Corporate Fortress)
This is MongoDB's paid, self-managed tier designed for large corporations with strict compliance rules, custom security requirements, or data residency mandates that prohibit them from using public cloud instances. It requires custom pricing negotiated with MongoDB sales, but it adds incredible enterprise-grade weapons to your arsenal: LDAP and Kerberos authentication, advanced audit logging, field-level encryption, and MongoDB Ops Manager for automated monitoring and backup orchestration. You also get 24/7 enterprise support with a guaranteed Service Level Agreement (SLA). The Catch: While it has all the bells and whistles, it is still self-managed. You still have to hire database administrators to run the underlying infrastructure.

3. MongoDB Atlas (The Set-It-and-Forget-It Cloud)
Then we have MongoDB Atlas. This is MongoDB's fully managed Database-as-a-Service (DaaS). It is not a "different" database; it runs the exact same document engine you know and love, but it hosts and deploys it entirely in the cloud across the provider of your choice: AWS, Microsoft Azure, or Google Cloud.

Atlas is the "easy button." It takes all the operational nightmares—backups, point-in-time restores, OS patches, automatic failover, and sharding—and handles them automatically behind the scenes.

What on Earth is "Fully Managed"?
When cloud providers say "fully managed," they usually mean they handle the hardware. But MongoDB Atlas takes it a step further. It handles the database operations.

Let’s look at what Atlas does for you while you're asleep:

Zero-Downtime Failover: Atlas deploys your database as a replica set (typically a minimum of three nodes across different availability zones). If the cloud provider's physical server hosting your primary node suddenly catches fire, Atlas instantly promotes a secondary node to primary in seconds. Your application barely notices.

Automatic Scaling: Running out of disk space? On Dedicated Dedicated clusters (M40 tiers and higher), Atlas will automatically scale up your storage tier once you hit 90% capacity. No manual volume expansion, no partition resizing.

Integrated Security: Security in Atlas is "always on". By default, it forces TLS encryption in transit, offers encryption at rest, and includes Client-Side Field-Level Encryption.

And for those who want to push privacy to the absolute limit, Atlas supports Queryable Encryption. Developed by the MongoDB Cryptography Research Group, this technology lets you search encrypted sensitive data (like prefix, suffix, and substring searches on PII) without the database ever decrypting the data on the server side!

Decoding the Billing: Credits and Consumption Units
Let's address the elephant in the room: How much does this cost?

NoSQL databases are famous for delivering incredible scale, but they are also famous for occasionally surprising developers with massive cloud bills if they aren't careful.

Atlas billing is pay-as-you-go. However, instead of charging you straight cash per microsecond, Atlas uses a consumption-based credit system:

100 Consumption Units = 1 Atlas Credit = $1.00 USD

Your application’s RAM, storage speed, IOPS, and active operations deplete your Consumption Units at a steady rate. To make sure you choose the right tier, Atlas provides three core structures:

Free Tier (M0): Great for learning and light prototyping. You get 512 MB of shared RAM and up to 5GB of storage in a sandbox environment.

Atlas Flex Tier: Replacing the legacy M2/M5 shared tiers, Flex is the default entry-level paid option. It charges a low base fee (around $8/month) and caps usage-based scaling at a predictable maximum (roughly $30/month). It supports search and change streams, making it perfect for development environments and MVPs.

Dedicated Clusters (M10 and larger): Dedicated clusters start at around $0.08 per hour (about $57/month) for an M10 tier. They scale all the way up to monstrous M700 clusters with 768 GB of RAM. These are designed for heavy production environments, supporting full sharded cluster deployments.

Looking Ahead: The Unified Data Platform
Here is the biggest reason I transitioned to Atlas: It is a unified data platform, not just a database.

When you run MongoDB yourself, if you want full-text search, you have to build an ETL pipeline and sync your data to an external search index like Elasticsearch. If you want to build an AI app, you have to spin up a vector database. If you want to process real-time data, you have to manage a Kafka stream processing layer.

With Atlas, you can turn these capabilities on with a single click because they are natively integrated:

Atlas Search: Google-like full-text search built directly on your collections.

Atlas Vector Search: Named the most loved vector database by developers in the Retool State of AI report. It lets you store vector embeddings right next to your operational data, and it even offers Automated Voyage AI Embeddings (which automatically generate embeddings as data is written).

Atlas Stream Processing: Generally available as of 2024, it lets you write event-driven, real-time stream processors using the same MongoDB Query API you already know.

Wrapping Up: SRE Without the Tears
By letting Atlas handle the infrastructure plumbing, you get to focus on what actually matters: building high-performance software.

Now that we have laid the foundation of what Atlas is and how it keeps our applications alive, we are finally ready to talk about optimization. Next time on ScalingDiaries, we are diving back into the deep end: How to right-size our Atlas nodes to save up to 50% on storage costs using MongoDB's brand new storage-optimized search nodes!

Are you running MongoDB locally, or have you made the leap to Atlas? Let me know in the comments below! 🍃

The Relational Hangover — How I Tried to Force SQL into MongoDB (and Cried in BSON)

Priya Singh — Fri, 03 Jul 2026 06:51:49 +0000

When I made the leap from PostgreSQL to MongoDB, I thought I was ready. I had read the brochures, watched the webinars, and even memorized the sales pitch: "A flexible schema database that scales horizontally!".

But there's a dark side to database migrations that no one warns you about: The Relational Hangover.

It’s that splitting headache you get when you try to force NoSQL to act like a relational database. You look at MongoDB’s clean, document-based universe and, instead of embracing its flexible document-first distributed engine, you start drawing imaginary lines, building invisible tables, and whispering "SELECT * FROM..." to yourself in the dark.

Today in ScalingDiaries, we are going to look at three schema design sins I committed during my transition—and how to fix them before your Atlas bill starts looking like a phone number.

Sin #1: The Postgres with a Mustache (Too Many Collections)
In PostgreSQL, normalization is law. You have a table for users, a table for orders, a table for items, and a table just to map user_roles. When I arrived in MongoDB, I did the exact same thing. I created a collection for every single entity.

I essentially drew a mustache on PostgreSQL, called it NoSQL, and went to lunch.

The Problem: MongoDB can handle multiple collections, but when you build a "relational schema in disguise," you are going to run into performance issues. Having too many collections degrades storage engine performance and creates unnecessary database complexity. In SQL, table joins are highly optimized. In MongoDB, trying to join ten different collections using native $lookup operations will drag your read performance down into the abyss.

The Cure: Embrace the document model! If data is always read together (like a user's address profile), embed it. MongoDB is built to store nested, rich JSON/BSON structures. Denormalize intentionally to avoid expensive reads.

Sin #2: The Unbounded Array (The "Infinite Comment" Trap)
My SQL brain told me: "Hey, a blog post has comments. Since MongoDB documents can hold arrays, let's just dump the comments into an array inside the blog post document!"

// My terrible, horrible, no-good schema
{
  "_id": ObjectId("64b2c3d4e5f6a7b8c9d0e2f3"),
  "title": "My First NoSQL App",
  "body": "It's going great!",
  "comments": [
    { "user": "alice", "text": "Awesome post!" },
    { "user": "bob", "text": "This schema is questionable." }
    // ... 10,000 comments later
  ]
}

It worked beautifully. Until it didn't.

The Problem: This is the classic Unbounded Array Anti-Pattern. In MongoDB, a single BSON document has a strict limit of 16 Megabytes. While 16MB sounds huge (that’s a lot of text!), a growing, unbounded array will eventually exceed this limit.

Long before you hit the 16MB ceiling, you’ll face severe performance degradation. Reading a blog post means loading all comments into memory. Building indexes on a rapidly growing array will put an immense strain on your database resources, slowing down read and write operations.

The Cure: If an array can grow indefinitely, do not embed it. Instead, use References. Store comments in a separate collection, with each comment pointing back to the post’s _id.

Alternatively, use the Subset Pattern: embed only the first 5 or 10 most recent comments in the blog post document for fast loading, and store the rest in a referenced collection for when the user clicks "View All."

Sin #3: The $lookup Addiction (Faking Joins)
Because I normalized everything (Sin #1), I needed a way to stitch my data back together. Enter $lookup—MongoDB's native way to perform left outer joins.

I became addicted. Need to show a user profile, their orders, and their order items? Just stack three $lookup stages in an aggregation pipeline!

db.users.aggregate([
  { $lookup: { from: "orders", localField: "_id", foreignField: "userId", as: "user_orders" } },
  { $unwind: "$user_orders" },
  { $lookup: { from: "items", localField: "user_orders.itemId", foreignField: "_id", as: "item_details" } }
])

The Problem: While $lookup is an incredibly powerful tool for analytics and stream processing (and works beautifully inside the new Atlas Stream Processing engine [2, 4]), using it in your core, high-frequency transactional queries is a recipe for disaster.

Each $lookup is computationally expensive. If you are running multiple $lookup operations on high-throughput queries, you are destroying MongoDB's performance advantage. You’re essentially paying a performance premium for a distributed database, only to force it to behave like a slow relational database.

The Cure: Design your schema around how your application queries data, not how the data naturally relates. If your dashboard needs to show a customer's name next to their order, denormalize and duplicate the customerName field directly inside the orders document. Yes, you have to manage updating it if their name changes, but your read queries will run at machine speed—sub-100ms latency.

The 2026 Verdict: Unlearn to Scale
Moving from SQL to NoSQL isn’t just a syntax change; it’s a psychological transition. If you are constantly fighting the document model, trying to enforce foreign key constraints, or relying on endless joins, you’re missing out on what makes MongoDB a powerhouse.

In 2026, with the release of MongoDB 8.3 delivering massive performance increases (up to 45% more reads and 35% more writes over MongoDB 8.0), the database is faster than ever. But a database is only as fast as the schema you design.

Stay tuned for Chapter 3 of ScalingDiaries, where we will explore how to right-size our Atlas nodes to save up to 50% on storage costs using the brand new storage-optimized search nodes!

Until then—stop joining, start embedding, and let your data be flexible. 🚀

Breaking the Tables – My Journey from Relational Databases to MongoDB

Priya Singh — Tue, 30 Jun 2026 16:43:15 +0000

For a long time, my comfort zone was built on rows, columns, and foreign keys. I lived in the world of strict relational databases, relying on strong consistency and complex multi-table joins to get things done. It felt safe, but as the applications I was building started to demand more, I hit a wall.

Here is the story of why I stepped out of the relational matrix, the hurdles I faced, and why MongoDB became my go-to engine for modern, scalable applications.

The Challenge: When Rows and Columns Weren't Enough

The shift started when my workloads evolved. I was dealing with rapid prototyping, massive write-heavy workloads, and an increasing need to integrate AI features.

While traditional relational databases like PostgreSQL have evolved into impressive "hybrid beasts" with features like native JSONB indexing and parallel query execution, I still felt the friction. Scaling a relational database horizontally for global, write-heavy applications is notoriously painful. I was spending too much time wrestling with schema migrations and worrying about latency rather than just shipping features.

I needed a database that didn't just store data, but adapted to it.

The Shift: Discovering the Document-First Engine

Making the leap to MongoDB was initially intimidating. Unlearning the instinct to normalize everything into a dozen different tables took time. But once I embraced the document model, the "aha" moments came quickly.

MongoDB is a document-first distributed engine that thrives on flexible schemas. It allowed me to rapidly prototype because the schema could dynamically evolve alongside my application code.

My Biggest Learnings

1. Horizontal Scaling Actually Works
In the relational world, massive write workloads often become bottlenecks. With MongoDB, I learned how to leverage sharded clusters for real-time applications and multi-region write clusters, which drastically lowered latency for globally distributed users.

2. AI is Built-In, Not Bolted On
As the AI boom took off, vector database usage among developers skyrocketed from 20% to 63.6% in just one year. Instead of stitching together a fragmented AI tech stack (which over 50% of developers say they are unsatisfied with), I found that MongoDB Atlas has Vector Search natively integrated. I was thrilled to see it voted the "most loved" vector database for the second year in a row in the 2024 Retool State of AI report. It makes building generative AI and Retrieval-Augmented Generation (RAG) applications seamless because the vector data lives right inside my existing collections.

3. Cost-Effective Infrastructure Matters
Scaling isn't just about handling more traffic; it's about doing it without burning cash. A huge learning curve was mastering how to size my search nodes. I discovered MongoDB's storage-optimized search nodes, which are engineered for workloads with massive index sizes. By using an 8:1 RAM-to-vCPU ratio, they provide more than double the storage capacity and can save up to 50% on dedicated search node storage costs, preventing you from overprovisioning expensive compute resources just to get more disk space.

The Verdict in 2026

The database landscape in 2026 is incredibly competitive. The debate shouldn't really be "Relational vs. MongoDB," but rather choosing the right tool for the right problem. If you need complex multi-table joins, relational is still king. But for read-heavy analytics, AI-first features, and flexible document storage, MongoDB is a powerhouse.

I’m starting ScalingDiaries to document exactly this kind of evolution. Next time, I’ll be diving deeper into schema design anti-patterns to avoid when moving from SQL to NoSQL.

Let’s build something massive together. 🚀