For a long time, SQL Server was how I thought about data. Tables, keys, joins, indexes and transactions were not just tools. They were the design itself. After years in that world, you think in rows and links before you think about how the app is used.
My early systems used strict, normalized designs. Third normal form, shared lookup tables, tight constraints and clear transaction boundaries gave me confidence. SQL Server was strong where it counted: consistent data, a smart query planner, great tools and steady behaviour in production. In large companies, that kind of trust is hard to beat.
For some years I also used stored procedures a lot. They kept business rules close to the data and could keep the app code simple. But they had costs too. Logic was tied to database releases. Older teams often did not keep them in version control well. And new people found it hard to learn a system whose rules were split between app code and T-SQL.
When Access Patterns Started to Change
Then apps moved toward smaller services and faster product changes, and the way we read and wrote data began to shift. Some data no longer fit neatly into split-up tables. We needed nested data, payloads that could change, and new features without a migration for every step. That is when MongoDB became a serious option.
Moving to MongoDB was not just a swap of tools. It was a new way of thinking. In SQL, you keep one shared copy of each fact and join tables to build views. In MongoDB, you shape each document around how it is read and written. You copy data on purpose, not by accident.
Modelling From Use Cases
The first lesson was to design from real use, not from old habits. In SQL, you might split data into many tables and join it back later. In MongoDB, you often keep data together when it is used together. Done well, this means simpler queries and fewer trips to the database. Done badly, it means copies that drift apart and are painful to update.
Indexes needed fresh care too. Both databases rely on them, but they behave in different ways. In MongoDB, a compound index that does not match your filters and sort order can hurt you fast. Checking query plans became a daily habit again, just like when I tuned SQL Server.
Aggregation Pipelines and Transactions
Aggregation pipelines were another big step. At first, they feel like a new language next to SQL. But once you see how the stages flow from one to the next, they are great for reshaping and summing up data. The trick is to keep them readable, and to avoid giant queries that no one can maintain.
People often see transactions as the big divide. In practice, design matters more than any feature list. MongoDB now supports transactions across documents. Still, the best results come from shaping documents so you rarely need them. Just because you can use large transactions does not mean you should.
Operations, Lifecycle and Migrations
In both worlds, I learned that monitoring is a must. Slow query logs, index health, locks, connection pools and memory use all matter. SQL Server has deep, proven tools for this. MongoDB has different ones that matter just as much. The key is to watch the right signals early.
Managing old data changed as well. In MongoDB, TTL indexes and archive jobs can do much of the work. In SQL Server, this often lives in partitions, archive tables or ETL jobs. Neither way is always better. Each fits different workloads and team habits.
Migrations changed in a quiet but important way. In SQL, migrations are strict, because the schema is fixed. MongoDB lets the shape of your data change bit by bit. But that freedom can hide tech debt if you lose track of document versions. I found it helped to add a clear version field to each document and run controlled jobs to update old ones.
Bringing the Team Along
How well the team worked together made a big difference. Developers with deep SQL skills sometimes rebuild SQL patterns inside MongoDB, which throws away much of its value. Other teams copy data everywhere with no rules, and the data drifts apart. The best teams are practical, but they agree clear rules for how data is shaped.
SQL Server or MongoDB? Often Both
Over time, I stopped seeing it as SQL Server or MongoDB. Each solves different problems well. SQL Server is still great for data full of links, strict transaction rules and mature reporting. MongoDB shines when apps read whole documents, the shape of data changes often, and APIs are built around those documents.
In real systems, a mix is often best. Use SQL where its guarantees are core. Use documents where speed of change and nested data need flexibility. Connect them through clear boundaries, events and ownership. Do not force one database to solve every problem.
If I had to sum up the journey: I did not move to MongoDB because it was new and SQL Server was old. I moved because the shape of the problems changed. Good engineering looks at the problem first and the tool second.
Today, my biggest lesson is this: data design is part of the architecture, not just plumbing. With either kind of database, quality comes from knowing how data is used, how consistent it must be, what limits you run under and what your team can handle. The choice of tool matters. Careful design matters more.
From SQL Server tables and joins to MongoDB documents and pipelines, the core idea has stayed the same. Design for real use, watch how it runs in production, and change it with care. That idea outlasts every database trend.