Behavior of No SQL

So when coming to the NoSQL world, it’s a bit different compared to SQL. When I first worked with DynamoDB, I thought, “what a wonderful behavior it has.” Everything felt fast, simple, almost like the database was doing less complaining and more working. No strict schemas, no heavy joins, no long setup. Just put data in and get it out quickly. At that time, it felt like I had found a smarter database.

But later, when I started learning more, I realized something interesting. DynamoDB wasn’t special because it was DynamoDB. It was behaving exactly the way NoSQL systems are designed to behave. That’s when it clicked that NoSQL is not just a database, it’s a different way of thinking about data.

In the SQL world, we grow up learning structure. You define tables, relationships, constraints. Everything is designed carefully before storing even a single record. The system guarantees correctness, strong consistency, ACID properties, and strict rules. It’s like building a well-planned city where every road and building is predefined.

NoSQL feels more like a rapidly growing town. You don’t wait to design everything. You allow things to evolve. You add data as needed, even if it doesn’t perfectly match previous records. That flexibility is not a side feature ,it’s the core behavior. Documents can look different from each other, attributes can appear and disappear, and the system doesn’t complain.

Then comes the part that confused me at first. Its the inconsistency. In SQL, you expect that once you write something, everyone sees the same value immediately. In NoSQL, that is not always true. At first, it feels wrong. But then you learn about distributed systems, and things start making sense.

This is where another important concept comes in BASE, which is often considered the opposite philosophy of ACID.

• Basically Available – the system always responds, even if the data might not be perfectly up to date
• Soft State – the system state can change over time, even without new input (because of replication and propagation)
• Eventual Consistency – if no new updates are made, the system will eventually become consistent

This idea explains why NoSQL systems behave the way they do. They are designed to keep working and stay responsive, even under failures, instead of blocking operations to maintain strict correctness at every moment.

NoSQL systems are built to run across multiple machines. Data is not in one place anymore. it is spread across nodes. Some nodes might respond faster than others, some might be temporarily disconnected. In that kind of environment, maintaining perfect consistency all the time is expensive. So NoSQL makes a conscious tradeoff. Instead of always being perfectly consistent, it chooses to always be available and to keep working even when parts of the system fail.

This is where the CAP theorem comes into play, even if you don’t notice it directly while coding. You can’t have everything consistency, availability, and partition tolerance at the same time. Most NoSQL systems choose availability and partition tolerance. That’s why they settle for eventual consistency. Data might not be perfectly up to date at this exact moment, but it will get there.

DynamoDB is designed as an AP system by default. That means it prioritizes availability and partition tolerance. Even if some nodes are unreachable, the system keeps serving requests. This is achieved through single leader and multiple replicas where data is replicated across multiple nodes and regions. Because of this, reads may return slightly stale data — this is eventual consistency.

However, DynamoDB also allows you to request strongly consistent reads, which gives you CP-like behavior for that operation. Under the hood, this means the read is served from the leader replica of that partition to ensure you get the latest committed value. So while the system is fundamentally AP, it can provide consistency when explicitly needed.

On the other hand, MongoDB follows a CP-oriented design by default. It uses a replica set architecture, which is closer to a master-slave model (though they call it primary-secondary). There is a single primary node that handles all writes, and multiple secondary nodes that replicate data from it.

Because MongoDB prioritizes consistency, writes are acknowledged based on write concern (often requiring replication to multiple nodes). If a network partition happens, MongoDB may sacrifice availability . For example, a minority partition cannot elect a primary and will reject writes to avoid inconsistency.

MongoDB handles failures using a leader election process. When the primary node goes down, the remaining nodes in the replica set hold an election. Each node votes, and a new primary is selected based on factors like replication state and priority. During this election window, the system may temporarily reject writes this is the tradeoff for maintaining strong consistency.

Interestingly, MongoDB can also be tuned toward availability (AP-like behavior). For example, by lowering write concerns or allowing reads from secondaries, you can trade consistency for availability — but this is a conscious choice, not the default.

And honestly, in many real-world systems, that’s good enough. When someone posts something on a social platform, it doesn’t matter if another user sees it one second later instead of instantly. What matters more is that the system responds quickly and doesn’t go down.

Another thing that stood out to me was how NoSQL handles growth. Instead of upgrading a single powerful machine, you just add more machines. This horizontal scaling feels natural in distributed systems. Along with that, techniques like sharding and replication quietly handle the heavy lifting. Data gets split across nodes for performance and copied across nodes for reliability. You don’t always see it happening, but it’s constantly working behind the scenes.

Over time, I also realized that NoSQL is not one thing. It’s a collection of ideas expressed through different models. Document databases let you store JSON-like data freely. Key-value stores focus on speed with simple lookups. Column stores optimize for large-scale analytics. Graph databases model relationships in a way relational databases struggle with. Each one follows the same underlying behavior but solves different kinds of problems.

Of course, this freedom comes with tradeoffs. You don’t get powerful joins like in SQL. You don’t always get a standard query language. You have to think differently about how you design your data. Sometimes you even duplicate data intentionally, something that would feel wrong in a normalized SQL design. But in NoSQL, it’s part of the design strategy to improve performance.

Looking back, what I initially saw as “cool features” in DynamoDB were actually reflections of a deeper philosophy. NoSQL systems are built to handle scale, failure, and flexibility. They are less about strict correctness at every moment and more about keeping the system responsive and resilient.

So now when I look at NoSQL, I don’t see a single database anymore. I see a set of design decisions — choices made to prioritize scalability, availability, and speed. And once you understand those choices, the behavior of NoSQL systems stops feeling strange and starts feeling very intentional.