They rely on the exact same data model concept of having a table where we first identify the row / key / item and then select some columns / values in order to retrieve the wanted cell / attribute.

Here is one quote from a relevant article:

"The top level data structure in Cassandra is the keyspace which is analogous to a relational database. The keyspace is the container for the tables and it is where you configure the replica count and placement. Keyspaces contain tables (formerly called column families) composed of rows and columns. A table schema must be defined at the time of table creation.

The top level structure for DynamoDB is the table which has the same functionality as the Cassandra table. Rows are items, and cells are attributes. In DynamoDB, it’s possible to define a schema for each item, rather than for the whole table.

Both tables store data in sparse rows—for a given row, they store only the columns present in that row. Each table must have a primary key that uniquely identifies rows or items. Every table must have a primary key which has two components."

Sounds like pretty much the same thing. So, why the difference in terminology?

Hey there,

having read the DynamoDB Book from Alex DeBrie and watched almost all content on YT from Rick and Alex, I constantly ask myself.. since you can basically model all kinds of relational data and denormalize classic RDBMS models to fit DynamoDB and it's going to perform amazing at any scale - when would you actually still prefer something like Postgres (RDS or Aurora)?

One thing I might imagine is, when you start with some project and have no clue about your near future access patterns.

Another thing I hear regularly - "We understand RDBMS and develop faster with it - we don't understand DynamoBD - all data in one table? Sounds wrong.".

Dynamo is harder to grasp and modelling takes more time and brainpower. Also, RDS and Aurora can scale to some crazy figures - it's hard to convince people to try DynamoDB if AWS offers RDBMS solutions that can also scale to 10.000 / 100.000 requests per second - I was actually not able to find any use case online where people needed to switch from RDS / Aurora to DynamoDB because of performance problems.

So.. have you had any real world experience with that? What's your usual choice?

Thx!

TL;DR:

Have I been indoctrinated into believing that NoSQL solutions like DDB (DynamoDB) are always the better architectural pattern, or are there valid scenarios to build a service on top of SQL. Assuming you are building (amazon, google, twitter, etc) massive scale applications, in large engineering orgs.

For typical, design Reddit, Twitter, etc style interview questions. Would I lose a lot of points for over reliance on NoSQL solutions like DDB.

Background Information:

So for background i've mostly done front end the past 10 years, but past few years have been picking up some java back-end stuff at my current job. Currently studying for a full stack interview at a new company.

My experience is mostly with building on top of DynamoDB as a persistence layer. Mostly because this is the default mode of operation for every new service built on my current team.

Many system design advice videos im seeing suggest using relation database, especially if you have any sort of relation data.

Is this actually good advice? When properly designed, DDB tables have 10ms or less response times. Are way easier to scale horizontally. Data joins when required can be done in your business logic layer. Most of the system designs that use SQL, end up building cache layers in front of the DB anyway. Which feel like an operational pain to manage, and are not immediately necessary with a properly designed set of DDB table.

In big corps, most of the time you are reliant on data from other teams services anyway. So rarely can you just rely on a single SQL query to resolve your entire data result.

The only time in my career ive used Relation DBs, was when building monolithic Django MVPs for quickly launching an idea to a limited set of customers. For that purpose, I think they work really well.