Read this answer

Relational databases are based on the relational model, an intuitive, straightforward way of representing data in tables. In a relational database, each row in the table is a record with a unique ID called the key. The columns of the table hold attributes of the data, and each record usually has a value for each attribute, making it easy to establish the relationships among data points.

Cassandra has tables.

    movie_id UUID,
    title TEXT,
    release_year INT,
    PRIMARY KEY (( movie_id ))

Data being relational has nothing to do with support of ACID properties.

Data being relational has nothing to do with normalised data

  1. Why Cassandra is not considered Relational database?

  2. Why Cassandra is considered NoSQL database? despite it has tables


Cassandra is not an RDBMS because it does not support the relational data model.

The fundamental assumption of the relational model is that all data is represented as mathematical n-ary relations, an n-ary relation being a subset of the Cartesian product of n domains


Instead, it models data as a key-value store, where the values are rows. But there's no requirement that all the "rows" in a "table" have the same "columns", as is the case in the relational model.

From Wikipedia:

Unlike a table in an RDBMS, different rows in the same column family do not have to share the same set of columns, and a column may be added to one or multiple rows at any time.[29]

Each key in Cassandra corresponds to a value which is an object. Each key has values as columns, and columns are grouped together into sets called column families. Thus, each key identifies a row of a variable number of elements. These column families could be considered then as tables. A table in Cassandra is a distributed multi dimensional map indexed by a key. Furthermore, applications can specify the sort order of columns within a Super Column or Simple Column family.



Why Cassandra is not Relational

The other answers are close (I will explain why each incomplete), but this snippet of text from the documentation highlights what exactly makes Cassandra non-relational:

Apache Cassandra does not have the concept of foreign keys or relational integrity.

The ability to enforce PK/FK relationships is integral to a RDBMS. To quote Codd's Relational Model for Database Management (emphasis mine):

1.2.4 Omission of Features When implementing a relational database management system, many questions arise regarding the relational model. Occasionally, support for some basic feature has been omitted due to it being assessed as useless. Unfortunately, the relational model has always had features that are inextricably intertwined. This means that omission of one feature of the model in a DBMS can inhibit implementation of numerous others. For example, omission of support for primary keys and foreign keys (defined in Section 1.8) jeopardizes the implementation of

• view updatability (see Chapter 17),

• the principal integrity constraints (see Chapter 13), and

• logical data independence (see Chapter 20).

You can change how the data is stored (Codd explicitly says all relations can be expressed as tables, not that they must be expressed as such), but if elements required to maintain the database in a consistent state are missing, the system cannot call itself a relational database.

Is Cassandra NoSQL?

In the sense that anything else is. NoSQL is largely a marketing term used to describe systems circumvented perceived shortcomings in relational databases, which they confused with the language, SQL.

We've seen a number of things marketed as "NoSQL" that are table/row oriented, using indexing methods common to RDBMs, and in the past few years, have added support for a subset of SQL.

In Cassandra's case, CQL is eerily similar to SQL, so you can see why the description is rather fuzzy.

Comments on Other Answers

I think it's very easy to get caught up on the physical implementation of data storage, as opposed to what framework exists for data.

Columnstore is a method for physically storing and retrieving data, it has nothing to do with the relational model.

Likewise, the idea of entities having optional/unspecified columns is not something unique to NoSQL - you can certainly implement a similar concept in a relational database either using subtypes and/or 6NF.

  • "foreign keys or relational integrity" have nothing to do with the relational theory, after which relational DBMSes are called thus. – mustaccio Dec 4 '20 at 21:48
  • @mustaccio My answer states it is Cassandra's inability to enforce relations. The foreign key is from their text, not mine. Certainly Cassandra could attempt to enforce relations through some other method, but they don't, so there you are. – bbaird Dec 4 '20 at 21:54
  • 2
    You conflate "relations" between tables involved in a referential integrity constraint, which I would probably call "relationships", and "relations", as sets of tuples, from the relational theory. These are different things. – mustaccio Dec 4 '20 at 22:12
  • 1
    @mustaccio "FK" & "FK constraint" are relational model concepts. (Although FK constraints are not the "relations" of the relational model; relationships/associations & tables are.) (FK constraints aren't relationships either. They are statements true in every situation/state.) – philipxy Dec 5 '20 at 8:23
  • 3
    The "relation" in "relational" is this en.wikipedia.org/wiki/Relation_(database) – Martin Smith Dec 5 '20 at 9:14

The way data is stored and represented in a NoSQL database system such as Cassandra is different than how it is stored and represented in a RDBMS. Despite having an object called a Table it doesn't catalog the data the same way as RDBMS does for a Table. For example, Cassandra stores the data in column store format. (Some RDBMS also use column stores, such as PostgreSQL *with extensions, but most are row store like Microsoft SQL Server, which can leverage different data structures for indexing like a B-Tree, for example.)

The main distinction is the algorithms in the Cassandra engine are designed in a way to be proficient in handling high varying or non-structural data efficiently, as opposed to a RDBMS which has a different set of algorithms for being performant with relational data.

You can read more about Cassandra here.

  • Storing the data in column store format, is just an abstraction for database user. User knows that data is getting stored in a table, where select query gives list of rows in a table – overexchange Dec 4 '20 at 20:59
  • 1
    It seems to me that the important aspect is the external representation - what the client sees - and not the internal implementation. Oracle, Postgres, DB2 etc would not cease to be relational if, say, they dropped BTree support. – Michael Green Dec 4 '20 at 21:03
  • True but if a RDBMS stripped everything under the hood that made it functional to support the external representation of the data to the user, then it wouldn't be much more of a relational database than storing your data in a bunch of XML files, or drawing your data on paper and putting related data into the same folder in real life. Extreme over-exaggeration, I know, but my point being is I don't think there's necessarily one concrete answer to this question, and I think both what the user sees and what is implemented in the database engine are equally important to drawing the line. – J.D. Dec 4 '20 at 21:12
  • and why Cassandra is considered as NoSQL? – overexchange Dec 4 '20 at 21:25
  • @overexchange Because it's designed to handle the scenarios a NoSQL database system is meant to handle, both from an efficient data management and storage perspective of what's going on under the hood and from a use-case perspective of what the end user would want to utilize Cassandra for (which again would be very varying structural or lack of structured data use cases). – J.D. Dec 4 '20 at 21:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.