The NoSQL Lie That Keeps Developers Overbuilding

本站添加: 2026-06-04

[00:00:00][snorts] >> You probably don't need no sequel.

[00:00:04]You probably need to stop using hypothetical scale as an excuse to avoid data discipline right now. That's the uncomfortable version of this argument. NoSQL isn't bad.

[00:00:18]DynamoDB, MongoDB, Redis, Cassandra style systems, they're real tools for real workloads.

[00:00:27]But a lot of teams don't choose them because they have a measured workload that demands them.

[00:00:34]They choose them because they want to move fast.

[00:00:37]They want to avoid schema or they want to prepare for some imagined future where SQL supposedly falls over.

[00:00:45]And that's kind of backwards. For most product teams, the default should still be relational.

[00:00:51]PostgreSQL, MySQL, SQLite, one of my favorites, MariaDB, systems like that.

[00:00:59]They're boring for a reason. They give you relationships, constraints, transactions, indexes, migrations, joins, and ad hoc SQL in plain English.

[00:01:10]They give the business a shared surface of truth.

[00:01:13]And most products need that more than they need theoretical flexibility. The mainstream story says serious modern systems eventually outgrow SQL. It sounds sophisticated because it borrows language from companies operating at some enormous scale. Amazon Dynamo, for example, was built for highly available key-value workloads. The Dynamo paper describes incremental scalability, high availability, and eventual consistency under Amazon shopping cart and service workloads. That's a legitimate engineering context, but that context isn't the same as building a customer dashboard or a billing workflow or an audit trail, or an internal admin tool, or a reporting feature, or a permission system. Quick thanks to DevStats for sponsoring this video. Most dashboards are great at making charts that everybody sees and nobody actions.

[00:02:12]DevStats is a lot more useful. It pulls together DORA, flow metrics, AI impact, and engineering investment, so everyone can see where the team is actually spending time, where delivery gets stuck, and what should be fixed. Check out DevStats. The link is up here and in the description. Back to the video. This is where teams get themselves into some serious trouble. They import the architectural language of scale without importing the actual scale problem. I mean, would you drive a train to work every day if you're not carrying anything or shipping anything? It's kind of overkill. A relational database asks some annoying questions very early.

[00:02:52]What's a customer? What's an account?

[00:02:54]What owns a subscription? What does active mean? What has to be unique? What can't be null? What changes together?

[00:03:02]What needs to be queried later? Those questions, they feel slow when you're trying to ship fast, but they're not bureaucracy. They're the domain becoming explicit. No SQL feels faster because it lets you postpone those questions. You can store the document. You can add fields later. You can let each service interpret the shape. You can move validation into application code, but that doesn't remove schema. It relocates schema. Every serious system has a schema. The only question is, where does it live? Is it explicit, reviewed, migrated, constrained, and visible, or is it implicit, duplicated, scattered across customers, and discovered during incidents.

[00:03:53]Schemaless usually doesn't mean there's no structure. It means the structure lives in application conventions, code paths, and tribal memory. That can be fine when records genuinely vary and the blast radius is kind of small. It becomes really painful when product, finance, support, security, leadership, and on-call engineers all need the same understanding of the same data. And that's the hidden tax. NoSQL can make writing data feel easy while making the business harder to reason about.

[00:04:27]Relational databases aren't just storage engines. They're operational truth services. A support engineer can inspect customer state. An on-call engineer can join across entities during an incident.

[00:04:41]Finance can reconcile subscriptions.

[00:04:44]Security can investigate access. Product can ask cross-entity questions that weren't perfectly known 6 months ago.

[00:04:52]With relational systems, joins, constraints, normalized data, and ad hoc SQL make those questions possible in a very direct way. With NoSQL, you may still answer those questions, but a lot of times you answer them by adding more machinery, streams, ETL, search indexes, warehouses, materialized views, duplicated read models, secondary indexes, custom repair jobs. Sometimes that architecture is necessary, but if you adopted NoSQL just to avoid modeling that data, you might spend the next year rebuilding the query flexibility that you just gave up. Now, the strongest case of NoSQL is not SQL is old. That's not a serious argument. I'm old. I still have some pretty serious advice and opinions. The serious argument is this.

[00:05:47]This specific workload has a specific shape, scale, latency need, availability requirement, or data model that a specialized store serves better. That's real. DynamoDB is a good example. Its own design guidance emphasizes identifying access patterns before designing tables and keys. You start with the application's reads and writes, then design around them. That's powerful when you understand the workload really well. It's risky when the product is still discovering the domain. If your access patterns are stable and business critical, access pattern first design can be excellent. If your business logic is changing every sprint, it can become a cage. MongoDB has a real place, too.

[00:06:32]Flexible schema and embedded related data can fit document-oriented use cases, especially when related data is usually retrieved as a whole aggregate.

[00:06:43]In other words, if you're always going to basically fetch this whole block of data, you might as well make it a block of data. But, MongoDB also has transaction documentation for a reason.

[00:06:53]Real applications might need atomicity across multiple documents, collections, or databases. When that happens, you're back in the world of consistency and transactions. Redis is also valuable, but mostly because it's specialized.

[00:07:07]Caches, queues, counters, locks, rate limits, leaderboards, session stores, feature flags, and idempotency keys.

[00:07:16]Ephemeral coordination.

[00:07:19]Those are good uses.

[00:07:21]They don't imply Redis should become the official system of record for your core business. Cassandra-style architectures emphasize distribution, replication, and high availability. That can matter. But again, those are tradeoffs. They're not free scale. Distributed systems force you to reason about partitions, consistency, and availability. Dynamo DB makes this visible with eventually consistent and strongly consistent reads. That's not a flaw. It's an explicit design choice, but it means engineers have to know when stale reads are acceptable and when they're not.

[00:08:00]If you're building billing, permission, entitlement, audit trails, financial records, or cross-entity workflows, that question isn't academic. Google Spanner is also instructive. It provides externally consistent distributed transactions using sophisticated infrastructure and clock synchronization. That tells us something important. Teams want distribution and relational style correctness at the same time.

[00:08:28]It also tells us that getting both is complex.

[00:08:32]So, don't buy a distributed system problem before you have a measured distributed system need. Bad relational schemas can absolutely be rigid. They can be over normalized, prematurely abstracted, bureaucratic, and painful to change, but relational systems also support change. Migrations support change. Constraints preserve assumption while you change. Indexes adapt access patterns. Transactions protect shared state. PostgreSQL even supports JSON and JSONB, JSON-specific operators, and indexing options. That doesn't mean every document workload belongs in PostgreSQL. It means a lot of teams reach for a document database when their relational database already offers controlled flexibility. The market evidence also doesn't support the idea that SQL lost. DB database engines continue to show relation databases [clears throat] like Oracle, MySQL, MariaDB, Microsoft SQL Server, PostgreSQL, and SQLite. They're the most widely used systems. Stack Overflow's 2024 developer survey lists PostgreSQL, MySQL, SQLite, and Microsoft SQL Server.

[00:09:47]They're among the most commonly used database technologies.

[00:09:50]And MongoDB and Redis, they're pretty high up there in the list, too. That's the real world. Mixed persistence, not database religion. So, here's the practical CTO rule. Use relational for your system of record.

[00:10:06]If the product has customers, accounts, permissions, subscriptions, invoices, approvals, audit trails, workflows, or reporting needs, start relational unless you have a concrete reason not to. Then add specialized stores. Redis for cache or coordination, search infrastructure for search, a warehouse for analytics, object storage for blobs, a document store for a specific aggregate, DynamoDB for a known access pattern-driven workload. That's a healthy polyglot persistence. There's one truth, which drives systems serving those specific needs. The only truth is derived systems serving specific needs. Before adopting NoSQL as a source of truth, you might require a simple document from the team. What are the exact reads and writes? What has to be strongly consistent? What can be stale?

[00:11:01]What are the failure modes? How will support inspect state? How will analytics query it? How will migrations work? How will data be repaired? Oh, you never need to fix your data? Well, that's because you haven't had production systems yet. What happens when the original developers leave?

[00:11:19]Scary one. If the team can't answer those questions, it's not ready for NoSQL. It's using a database choice to avoid domain clarity, and that's the leadership issue. NoSQL is dangerous when it becomes a way to call ambiguity flexibility. Schema is not the enemy of speed. Unexamined schema is. One way or another, you're going to pay the bill.

[00:11:44]You can pay it now, or you can pay it later with interest. Use relational systems by default. Use no sequels for very specific purposes, very deliberate ones.

[00:11:56]And after the workload proves it's worth the tax, because the database that makes version one easy can make year three miserable. And the boring database on day one might be the reason your team can still understand the business on day 1,000.