Learn about seven different database paradigms and what they do best. https://fireship.io/lessons/top-seven-database-paradigms/

00:00 Intro
00:45 Key-value
01:48 Wide Column
02:47 Document
04:05 Relational
06:21 Graph
07:22 Search Engine
08:27 Multi-model

#learntocode #data

Learn more about MeiliSearch https://fireship.io/lessons/meilisearch-firebase-google-cloud/

Install the quiz app 🤓

iOS https://itunes.apple.com/us/app/fireship/id1462592372?mt=8
Android https://play.google.com/store/apps/details?id=io.fireship.quizapp

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

My VS Code Theme

- Atom One Dark 
- vscode-icons
- Fira Code Font
2024-02-04T06:08:05.417Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
5215518d-8c52-4c52-a0bc-53d46d98960b
0484aaada95ec7f65d6b1089543f27af043d2c1672216d22128aa8911ef6457c
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
My dad used to tell me, use the right tool for the job and not vice versa.
When it comes to app development, choosing the right database is one of the single most important decisions that you'll ever make.
In today's video, we'll look at 7 different database paradigms, along with some databases you've probably heard of and some others that you haven't.
We'll look at how they work from a technical perspective, But most importantly, we'll try to understand what they're best used for.
Because my dad also used to tell me, don't bring a knife to a gunfight.
If you're new here, like and Subscribe.
And also check out my new top seven playlist for more videos like this.
Our list will start from the most simple type of database and gradually become more complex as we get to number 7.
And that brings us to our first paradigm, the key value database.
Popular databases in this space include Redis, Memcached, and Etcd.
The database itself is structured almost like a JavaScript object or a Python dictionary.
You have a set of keys where every key is unique and points to some value.
In Redis, for example, we can read and write data using commands.
We use the set command followed by a key and a value to write data, then the git command to retrieve that data in the future.
In the case of Redis and Memcached, all the data is held in the machine's memory as opposed to most other databases that keep all their data on the disk.
This limits the amount of data you can store.
However, it makes the database extremely fast because it doesn't require a round trip to the disk for every operation.
In addition, it doesn't perform queries, joins, or anything like that, so your data modeling options are very limited, but, again, it's extremely fast, like sub millisecond fast.
You wouldn't wanna use a key value store for your main app data.
Most often, they're used as a cache to reduce data latency.
Apps like Twitter, GitHub, and Snapchat I'll use Redis for real time delivery of their data.
There are other use cases beyond caching, like message queues, pubsub, and gaming leaderboards, But more often than not, key value databases are used as a cache on top of some other persistent data layer.
Now a database that only supports key value pairs is obviously pretty limited, And that brings us to the wide column database.
Popular options in this family include Cassandra and HBase.
A wide column database is like you took a key value database and added a second dimension to it.
At the outer layer, you have a key space, which holds 1 or more column families, and each column family holds a set of ordered rows.
This makes it possible to group related data together.
But unlike a relational database, it doesn't have a schema, so it can handle unstructured data.
This is nice for developers because you get a query language called CQL that's very similar to SQL, although much more limited and you can't do joins.
However, it's much easier to scale up and replicate data across multiple nodes.
Unlike an SQL database, it's decentralized and can scale horizontally.
A popular use case is for scaling a large amount of time series data, like records from an IoT device, weather sensors, or in the case of Netflix, a history of the different shows you've watched.
It's often used in situations where you have frequent writes but infrequent updates and reads.
It's not going to be your primary app database.
For that, you'll need something more general purpose, like a document oriented database.
Popular options in the document family include MongoDB, Firestore, DynamoDB, CouchDB, and a few others.
In this paradigm, you have documents, where each document is a container for key value pairs.
They're unstructured and don't require a schema, and the documents are grouped together in collections.
Fields within a collection can be indexed, And collections can be organized into a logical hierarchy, allowing you to model and retrieve relational data to a pretty significant degree.
They don't support joins, So instead of normalizing your data into a bunch of small parts, you're encouraged to embed the data into a single document.
This creates a trade off where reads from a front end application are much faster.
However, writing or updating data tends to be more complex.
Document databases are far more general purpose than the other options we've looked at so far.
From a developer perspective, they're very easy to use.
They're often suitable for mobile games, IoT, content management, and many other use cases.
If you're not exactly sure how your data is structured at this point, a document database is probably the best place to start.
Where they generally fall short is when you have a lot of disconnected but related data that is updated often, like a social app that has many users who have many friends, who have many comments, who have many likes, and you wanna see all the comments that your friends like.
Data like this needs to be joined, and it's not easily done in a document database at scale.
Luckily, we have this thing that's been around forever called the relational database.
You're likely familiar with this type of database with flavors like MySQL, Postgres, SQL Server, and many others.
They've been around for nearly 50 years and continue to be one of the most popular types of databases in today's world.
They were originally conceived by a computer scientist named Ted Codd.
He worked for IBM and spent years working out his theories on relational data modeling.
You can read his original paper online, and most of it goes way over my head.
But you can appreciate the amount of math and science that went into the development of relational databases, and that's very likely why they remain so popular today.
A few years later, this would inspire the development of SQL or Structured Query Language or SQL if you prefer.
It's a special type of programming language called a query which that allows you to access and write data in the database.
Okay.
But what do we actually mean when we say relational database?
Well, imagine you have a facility that builds airplanes.
The facility is your database, and on that database, you might have different warehouses that hold different parts, like engines, wheels, and so on.
Each warehouse is like a database table for holding a certain type of part.
Each individual part has a serial number to uniquely identify it, and you can think of an individual part as a row in a table.
So now that we have all these parts separated into different warehouses, how do we build an airplane?
That's where relationships come in.
We can build an airplane by referencing the unique ID of the different parts that go into it.
Notice how each part has its own unique ID.
This is known as its primary key, then it defines its various parts by referencing their IDs.
These are known as foreign because they reference data in a different table.
Now if we want to join all this data together, we can run a query to do that.
So the main takeaway here is that an SQL database organizes data in its smallest normal form.
However, a potential drawback here is that it requires a schema.
If you don't know the right data shape upfront, they can be a little harder to work with.
SQL databases are also ACID compliant, which means whenever there's a transaction in the database, Data validity is guaranteed even if there are network or hardware failures.
That's essential for things like banks and financial institutions, but it makes this type of database inherently more difficult to scale.
However, it's worth noting that there are modern SQL databases like Cockroach that are specifically designed to operate at scale.
In any case, relational databases remain the most Popular type of database in production today.
But what if instead of modeling a relationship in a schema, we just treated the relationship itself as data?
Enter the graph database, where your data is represented as nodes and the relationships between them as edges.
Popular options in this space include Neo 4J and d graph.
Let's imagine we want to set up a many to many relationship in an SQL database.
We do that by setting up a join table with the foreign keys that define the relationship.
In a graph database, we don't need this middleman table.
We just define an edge and connect it to the other record.
We can now query this data with a statement that's much more concise and readable.
In addition, we can achieve much better performance, especially on larger datasets.
Graph databases can be a great alternative to SQL, especially if you're running a lot of joins and performance has taken a hit because of that.
They're often used for fraud detection in finance, for building internal knowledge graphs within companies, and to power recommendation engines like the one used by Airbnb.
Now let's imagine you want to build something like Google.
A user provides a small amount of text, Then your database needs to return the most relevant results ranked in the proper order from a huge amount of data.
For that, you're going to want a full text search engine.
Most of the databases in this space are based on top of the Apache Lucene project, which has been around since 1999, like Solr and Elasticsearch.
In addition, we have cloud based options like Algolia and my new personal favorite, Melee Search, a Rust based full text search engine.
If you wanna check it out, I have a full tutorial on Fireship IO for Chrome members.
From a developer perspective, they work very similar to a document oriented database.
You start with an index, then you add a bunch of data objects to it.
The difference is that under the hood, the search database will analyze all the text in the document and create an index of the searchable terms.
So, essentially, it works just like the index that you would find in the back of a textbook.
When a user performs a search, it only has to scan the index as opposed to every document in the database, and that makes it very fast even on large datasets.
The database can also run a variety of different algorithms to rank those results, filter out irrelevant hits, handle typos, and so on.
This does add a lot of overhead and they can be expensive to run at scale, but at the same time, they can add a ton of value to the user experience if you're building something like a type ahead search box.
And with that, we've reached number 7, the multi model database, which in my opinion is the most exciting paradigm on this list.
There are a few different options out there, but the database I want to focus on here is FaunaDB, which is very different than anything else we've looked at so far.
If you're a front end developer, all you really care about is the data that you consume in the front end application.
You just want some JSON.
You don't wanna have to think about data modeling, schemas, replication, shards, or anything like that.
With FaunaDB, you describe how you want to access your data using GraphQL.
In this example, we have a user model and a post model, where a user can have many posts.
If we upload our GraphQL scheme in a fauna, It automatically creates collections where we can store data and an index to query the data.
Behind the scenes, it's figuring out how to take advantage of multiple database paradigms, like graph, relational, and document, and determining how to best use these paradigms based on the GraphQL code you provided.
You create data by adding documents to collections, just like you would with a document database.
But you're not stuck with the inherent limitations when it comes to data modeling.
On top of that, it's ACID compliant, extremely fast, and you never have to worry about provisioning the actual infrastructure.
You just decide how you wanna consume your data, and you let the cloud figure everything else out for you.
I'm gonna go ahead and wrap things up there.
We didn't cover every single database paradigm.
There's a few others that you might wanna know about, like time series databases and also data warehouses.
And if you wanna learn advanced data modeling concepts, consider becoming a pro member at FireShip IO and taking the Firestore data modeling like, course.
Thanks for watching, and I will see you in the next one.

Speaker 0: My dad used to tell me, use the right tool for the job and not vice versa. When it comes to app development, choosing the right database is one of the single most important decisions that you'll ever make. In today's video, we'll look at 7 different database paradigms, along with some databases you've probably heard of and some others that you haven't. We'll look at how they work from a technical perspective, But most importantly, we'll try to understand what they're best used for. Because my dad also used to tell me, don't bring a knife to a gunfight.

If you're new here, like and Subscribe. And also check out my new top seven playlist for more videos like this. Our list will start from the most simple type of database and gradually become more complex as we get to number 7. And that brings us to our first paradigm, the key value database. Popular databases in this space include Redis, Memcached, and Etcd.

The database itself is structured almost like a JavaScript object or a Python dictionary. You have a set of keys where every key is unique and points to some value. In Redis, for example, we can read and write data using commands. We use the set command followed by a key and a value to write data, then the git command to retrieve that data in the future. In the case of Redis and Memcached, all the data is held in the machine's memory as opposed to most other databases that keep all their data on the disk.

This limits the amount of data you can store. However, it makes the database extremely fast because it doesn't require a round trip to the disk for every operation. In addition, it doesn't perform queries, joins, or anything like that, so your data modeling options are very limited, but, again, it's extremely fast, like sub millisecond fast. You wouldn't wanna use a key value store for your main app data. Most often, they're used as a cache to reduce data latency.

Apps like Twitter, GitHub, and Snapchat I'll use Redis for real time delivery of their data. There are other use cases beyond caching, like message queues, pubsub, and gaming leaderboards, But more often than not, key value databases are used as a cache on top of some other persistent data layer. Now a database that only supports key value pairs is obviously pretty limited, And that brings us to the wide column database. Popular options in this family include Cassandra and HBase. A wide column database is like you took a key value database and added a second dimension to it.

At the outer layer, you have a key space, which holds 1 or more column families, and each column family holds a set of ordered rows. This makes it possible to group related data together. But unlike a relational database, it doesn't have a schema, so it can handle unstructured data. This is nice for developers because you get a query language called CQL that's very similar to SQL, although much more limited and you can't do joins. However, it's much easier to scale up and replicate data across multiple nodes.

Unlike an SQL database, it's decentralized and can scale horizontally. A popular use case is for scaling a large amount of time series data, like records from an IoT device, weather sensors, or in the case of Netflix, a history of the different shows you've watched. It's often used in situations where you have frequent writes but infrequent updates and reads. It's not going to be your primary app database. For that, you'll need something more general purpose, like a document oriented database.

Popular options in the document family include MongoDB, Firestore, DynamoDB, CouchDB, and a few others. In this paradigm, you have documents, where each document is a container for key value pairs. They're unstructured and don't require a schema, and the documents are grouped together in collections. Fields within a collection can be indexed, And collections can be organized into a logical hierarchy, allowing you to model and retrieve relational data to a pretty significant degree. They don't support joins, So instead of normalizing your data into a bunch of small parts, you're encouraged to embed the data into a single document.

This creates a trade off where reads from a front end application are much faster. However, writing or updating data tends to be more complex. Document databases are far more general purpose than the other options we've looked at so far. From a developer perspective, they're very easy to use. They're often suitable for mobile games, IoT, content management, and many other use cases.

If you're not exactly sure how your data is structured at this point, a document database is probably the best place to start. Where they generally fall short is when you have a lot of disconnected but related data that is updated often, like a social app that has many users who have many friends, who have many comments, who have many likes, and you wanna see all the comments that your friends like. Data like this needs to be joined, and it's not easily done in a document database at scale. Luckily, we have this thing that's been around forever called the relational database. You're likely familiar with this type of database with flavors like MySQL, Postgres, SQL Server, and many others.

They've been around for nearly 50 years and continue to be one of the most popular types of databases in today's world. They were originally conceived by a computer scientist named Ted Codd. He worked for IBM and spent years working out his theories on relational data modeling. You can read his original paper online, and most of it goes way over my head. But you can appreciate the amount of math and science that went into the development of relational databases, and that's very likely why they remain so popular today.

A few years later, this would inspire the development of SQL or Structured Query Language or SQL if you prefer. It's a special type of programming language called a query which that allows you to access and write data in the database. Okay. But what do we actually mean when we say relational database? Well, imagine you have a facility that builds airplanes.

The facility is your database, and on that database, you might have different warehouses that hold different parts, like engines, wheels, and so on. Each warehouse is like a database table for holding a certain type of part. Each individual part has a serial number to uniquely identify it, and you can think of an individual part as a row in a table. So now that we have all these parts separated into different warehouses, how do we build an airplane? That's where relationships come in.

We can build an airplane by referencing the unique ID of the different parts that go into it. Notice how each part has its own unique ID. This is known as its primary key, then it defines its various parts by referencing their IDs. These are known as foreign because they reference data in a different table. Now if we want to join all this data together, we can run a query to do that.

So the main takeaway here is that an SQL database organizes data in its smallest normal form. However, a potential drawback here is that it requires a schema. If you don't know the right data shape upfront, they can be a little harder to work with. SQL databases are also ACID compliant, which means whenever there's a transaction in the database, Data validity is guaranteed even if there are network or hardware failures. That's essential for things like banks and financial institutions, but it makes this type of database inherently more difficult to scale.

However, it's worth noting that there are modern SQL databases like Cockroach that are specifically designed to operate at scale. In any case, relational databases remain the most Popular type of database in production today. But what if instead of modeling a relationship in a schema, we just treated the relationship itself as data? Enter the graph database, where your data is represented as nodes and the relationships between them as edges. Popular options in this space include Neo 4J and d graph.

Let's imagine we want to set up a many to many relationship in an SQL database. We do that by setting up a join table with the foreign keys that define the relationship. In a graph database, we don't need this middleman table. We just define an edge and connect it to the other record. We can now query this data with a statement that's much more concise and readable.

In addition, we can achieve much better performance, especially on larger datasets. Graph databases can be a great alternative to SQL, especially if you're running a lot of joins and performance has taken a hit because of that. They're often used for fraud detection in finance, for building internal knowledge graphs within companies, and to power recommendation engines like the one used by Airbnb. Now let's imagine you want to build something like Google. A user provides a small amount of text, Then your database needs to return the most relevant results ranked in the proper order from a huge amount of data.

For that, you're going to want a full text search engine. Most of the databases in this space are based on top of the Apache Lucene project, which has been around since 1999, like Solr and Elasticsearch. In addition, we have cloud based options like Algolia and my new personal favorite, Melee Search, a Rust based full text search engine. If you wanna check it out, I have a full tutorial on Fireship IO for Chrome members. From a developer perspective, they work very similar to a document oriented database.

You start with an index, then you add a bunch of data objects to it. The difference is that under the hood, the search database will analyze all the text in the document and create an index of the searchable terms. So, essentially, it works just like the index that you would find in the back of a textbook. When a user performs a search, it only has to scan the index as opposed to every document in the database, and that makes it very fast even on large datasets. The database can also run a variety of different algorithms to rank those results, filter out irrelevant hits, handle typos, and so on.

This does add a lot of overhead and they can be expensive to run at scale, but at the same time, they can add a ton of value to the user experience if you're building something like a type ahead search box. And with that, we've reached number 7, the multi model database, which in my opinion is the most exciting paradigm on this list. There are a few different options out there, but the database I want to focus on here is FaunaDB, which is very different than anything else we've looked at so far. If you're a front end developer, all you really care about is the data that you consume in the front end application. You just want some JSON.

You don't wanna have to think about data modeling, schemas, replication, shards, or anything like that. With FaunaDB, you describe how you want to access your data using GraphQL. In this example, we have a user model and a post model, where a user can have many posts. If we upload our GraphQL scheme in a fauna, It automatically creates collections where we can store data and an index to query the data. Behind the scenes, it's figuring out how to take advantage of multiple database paradigms, like graph, relational, and document, and determining how to best use these paradigms based on the GraphQL code you provided.

You create data by adding documents to collections, just like you would with a document database. But you're not stuck with the inherent limitations when it comes to data modeling. On top of that, it's ACID compliant, extremely fast, and you never have to worry about provisioning the actual infrastructure. You just decide how you wanna consume your data, and you let the cloud figure everything else out for you. I'm gonna go ahead and wrap things up there.

We didn't cover every single database paradigm. There's a few others that you might wanna know about, like time series databases and also data warehouses. And if you wanna learn advanced data modeling concepts, consider becoming a pro member at FireShip IO and taking the Firestore data modeling like, course. Thanks for watching, and I will see you in the next one.
My dad used to tell me, use the right tool for the job and not vice versa. When it comes to app development, choosing the right database is one of the single most important decisions that you'll ever make. In today's video, we'll look at 7 different database paradigms, along with some databases you've probably heard of and some others that you haven't. We'll look at how they work from a technical perspective, But most importantly, we'll try to understand what they're best used for. Because my dad also used to tell me, don't bring a knife to a gunfight. If you're new here, like and Subscribe. And also check out my new top seven playlist for more videos like this. Our list will start from the most simple type of database and gradually become more complex as we get to number 7. And that brings us to our first paradigm, the key value database. Popular databases in this space include Redis, Memcached, and Etcd. The database itself is structured almost like a JavaScript object or a Python dictionary. You have a set of keys where every key is unique and points to some value. In Redis, for example, we can read and write data using commands. We use the set command followed by a key and a value to write data, then the git command to retrieve that data in the future. In the case of Redis and Memcached, all the data is held in the machine's memory as opposed to most other databases that keep all their data on the disk. This limits the amount of data you can store. However, it makes the database extremely fast because it doesn't require a round trip to the disk for every operation. In addition, it doesn't perform queries, joins, or anything like that, so your data modeling options are very limited, but, again, it's extremely fast, like sub millisecond fast. You wouldn't wanna use a key value store for your main app data. Most often, they're used as a cache to reduce data latency. Apps like Twitter, GitHub, and Snapchat I'll use Redis for real time delivery of their data. There are other use cases beyond caching, like message queues, pubsub, and gaming leaderboards, But more often than not, key value databases are used as a cache on top of some other persistent data layer. Now a database that only supports key value pairs is obviously pretty limited, And that brings us to the wide column database. Popular options in this family include Cassandra and HBase. A wide column database is like you took a key value database and added a second dimension to it. At the outer layer, you have a key space, which holds 1 or more column families, and each column family holds a set of ordered rows. This makes it possible to group related data together. But unlike a relational database, it doesn't have a schema, so it can handle unstructured data. This is nice for developers because you get a query language called CQL that's very similar to SQL, although much more limited and you can't do joins. However, it's much easier to scale up and replicate data across multiple nodes. Unlike an SQL database, it's decentralized and can scale horizontally. A popular use case is for scaling a large amount of time series data, like records from an IoT device, weather sensors, or in the case of Netflix, a history of the different shows you've watched. It's often used in situations where you have frequent writes but infrequent updates and reads. It's not going to be your primary app database. For that, you'll need something more general purpose, like a document oriented database. Popular options in the document family include MongoDB, Firestore, DynamoDB, CouchDB, and a few others. In this paradigm, you have documents, where each document is a container for key value pairs. They're unstructured and don't require a schema, and the documents are grouped together in collections. Fields within a collection can be indexed, And collections can be organized into a logical hierarchy, allowing you to model and retrieve relational data to a pretty significant degree. They don't support joins, So instead of normalizing your data into a bunch of small parts, you're encouraged to embed the data into a single document. This creates a trade off where reads from a front end application are much faster. However, writing or updating data tends to be more complex. Document databases are far more general purpose than the other options we've looked at so far. From a developer perspective, they're very easy to use. They're often suitable for mobile games, IoT, content management, and many other use cases. If you're not exactly sure how your data is structured at this point, a document database is probably the best place to start. Where they generally fall short is when you have a lot of disconnected but related data that is updated often, like a social app that has many users who have many friends, who have many comments, who have many likes, and you wanna see all the comments that your friends like.
databases
data management
documentation
data
websites
technology
publishing
data analysis
computer science
firearms
software
Data like this needs to be joined, and it's not easily done in a document database at scale. Luckily, we have this thing that's been around forever called the relational database. You're likely familiar with this type of database with flavors like MySQL, Postgres, SQL Server, and many others. They've been around for nearly 50 years and continue to be one of the most popular types of databases in today's world. They were originally conceived by a computer scientist named Ted Codd. He worked for IBM and spent years working out his theories on relational data modeling. You can read his original paper online, and most of it goes way over my head. But you can appreciate the amount of math and science that went into the development of relational databases, and that's very likely why they remain so popular today. A few years later, this would inspire the development of SQL or Structured Query Language or SQL if you prefer. It's a special type of programming language called a query which that allows you to access and write data in the database. Okay. But what do we actually mean when we say relational database? Well, imagine you have a facility that builds airplanes. The facility is your database, and on that database, you might have different warehouses that hold different parts, like engines, wheels, and so on. Each warehouse is like a database table for holding a certain type of part. Each individual part has a serial number to uniquely identify it, and you can think of an individual part as a row in a table. So now that we have all these parts separated into different warehouses, how do we build an airplane? That's where relationships come in. We can build an airplane by referencing the unique ID of the different parts that go into it. Notice how each part has its own unique ID.
databases
aircraft
data management
research
intellectual property
data
computer science
machine learning
air travel
aerospace
This is known as its primary key, then it defines its various parts by referencing their IDs.
These are known as foreign because they reference data in a different table. Now if we want to join all this data together, we can run a query to do that. So the main takeaway here is that an SQL database organizes data in its smallest normal form. However, a potential drawback here is that it requires a schema. If you don't know the right data shape upfront, they can be a little harder to work with. SQL databases are also ACID compliant, which means whenever there's a transaction in the database, Data validity is guaranteed even if there are network or hardware failures. That's essential for things like banks and financial institutions, but it makes this type of database inherently more difficult to scale. However, it's worth noting that there are modern SQL databases like Cockroach that are specifically designed to operate at scale. In any case, relational databases remain the most Popular type of database in production today. But what if instead of modeling a relationship in a schema, we just treated the relationship itself as data? Enter the graph database, where your data is represented as nodes and the relationships between them as edges. Popular options in this space include Neo 4J and d graph. Let's imagine we want to set up a many to many relationship in an SQL database. We do that by setting up a join table with the foreign keys that define the relationship. In a graph database, we don't need this middleman table. We just define an edge and connect it to the other record. We can now query this data with a statement that's much more concise and readable. In addition, we can achieve much better performance, especially on larger datasets. Graph databases can be a great alternative to SQL, especially if you're running a lot of joins and performance has taken a hit because of that. They're often used for fraud detection in finance, for building internal knowledge graphs within companies, and to power recommendation engines like the one used by Airbnb. Now let's imagine you want to build something like Google. A user provides a small amount of text, Then your database needs to return the most relevant results ranked in the proper order from a huge amount of data. For that, you're going to want a full text search engine. Most of the databases in this space are based on top of the Apache Lucene project, which has been around since 1999, like Solr and Elasticsearch. In addition, we have cloud based options like Algolia and my new personal favorite, Melee Search, a Rust based full text search engine.
databases
google
data management
data
machine learning
If you wanna check it out, I have a full tutorial on Fireship IO for Chrome members.
From a developer perspective, they work very similar to a document oriented database. You start with an index, then you add a bunch of data objects to it. The difference is that under the hood, the search database will analyze all the text in the document and create an index of the searchable terms. So, essentially, it works just like the index that you would find in the back of a textbook. When a user performs a search, it only has to scan the index as opposed to every document in the database, and that makes it very fast even on large datasets. The database can also run a variety of different algorithms to rank those results, filter out irrelevant hits, handle typos, and so on. This does add a lot of overhead and they can be expensive to run at scale, but at the same time, they can add a ton of value to the user experience if you're building something like a type ahead search box. And with that, we've reached number 7, the multi model database, which in my opinion is the most exciting paradigm on this list. There are a few different options out there, but the database I want to focus on here is FaunaDB, which is very different than anything else we've looked at so far. If you're a front end developer, all you really care about is the data that you consume in the front end application. You just want some JSON. You don't wanna have to think about data modeling, schemas, replication, shards, or anything like that. With FaunaDB, you describe how you want to access your data using GraphQL. In this example, we have a user model and a post model, where a user can have many posts. If we upload our GraphQL scheme in a fauna, It automatically creates collections where we can store data and an index to query the data. Behind the scenes, it's figuring out how to take advantage of multiple database paradigms, like graph, relational, and document, and determining how to best use these paradigms based on the GraphQL code you provided. You create data by adding documents to collections, just like you would with a document database. But you're not stuck with the inherent limitations when it comes to data modeling. On top of that, it's ACID compliant, extremely fast, and you never have to worry about provisioning the actual infrastructure. You just decide how you wanna consume your data, and you let the cloud figure everything else out for you. I'm gonna go ahead and wrap things up there. We didn't cover every single database paradigm. There's a few others that you might wanna know about, like time series databases and also data warehouses. And if you wanna learn advanced data modeling concepts, consider becoming a pro member at FireShip IO and taking the Firestore data modeling like, course. Thanks for watching, and I will see you in the next one.
databases
data management
modeling
data
wildlife
google
data analysis
documentation
My dad used to tell me, use the right tool for the job and not vice versa. When it comes to app development, choosing the right database is one of the single most important decisions that you'll ever make. In today's video, we'll look at 7 different database paradigms, along with some databases you've probably heard of and some others that you haven't. We'll look at how they work from a technical perspective, But most importantly, we'll try to understand what they're best used for. Because my dad also used to tell me, don't bring a knife to a gunfight. If you're new here, like and Subscribe. And also check out my new top seven playlist for more videos like this. Our list will start from the most simple type of database and gradually become more complex as we get to number 7. And that brings us to our first paradigm, the key value database. Popular databases in this space include Redis, Memcached, and Etcd. The database itself is structured almost like a JavaScript object or a Python dictionary. You have a set of keys where every key is unique and points to some value. In Redis, for example, we can read and write data using commands. We use the set command followed by a key and a value to write data, then the git command to retrieve that data in the future. In the case of Redis and Memcached, all the data is held in the machine's memory as opposed to most other databases that keep all their data on the disk. This limits the amount of data you can store. However, it makes the database extremely fast because it doesn't require a round trip to the disk for every operation. In addition, it doesn't perform queries, joins, or anything like that, so your data modeling options are very limited, but, again, it's extremely fast, like sub millisecond fast. You wouldn't wanna use a key value store for your main app data. Most often, they're used as a cache to reduce data latency. Apps like Twitter, GitHub, and Snapchat I'll use Redis for real time delivery of their data. There are other use cases beyond caching, like message queues, pubsub, and gaming leaderboards, But more often than not, key value databases are used as a cache on top of some other persistent data layer. Now a database that only supports key value pairs is obviously pretty limited, And that brings us to the wide column database. Popular options in this family include Cassandra and HBase. A wide column database is like you took a key value database and added a second dimension to it. At the outer layer, you have a key space, which holds 1 or more column families, and each column family holds a set of ordered rows. This makes it possible to group related data together. But unlike a relational database, it doesn't have a schema, so it can handle unstructured data. This is nice for developers because you get a query language called CQL that's very similar to SQL, although much more limited and you can't do joins. However, it's much easier to scale up and replicate data across multiple nodes. Unlike an SQL database, it's decentralized and can scale horizontally. A popular use case is for scaling a large amount of time series data, like records from an IoT device, weather sensors, or in the case of Netflix, a history of the different shows you've watched. It's often used in situations where you have frequent writes but infrequent updates and reads. It's not going to be your primary app database. For that, you'll need something more general purpose, like a document oriented database. Popular options in the document family include MongoDB, Firestore, DynamoDB, CouchDB, and a few others. In this paradigm, you have documents, where each document is a container for key value pairs. They're unstructured and don't require a schema, and the documents are grouped together in collections. Fields within a collection can be indexed, And collections can be organized into a logical hierarchy, allowing you to model and retrieve relational data to a pretty significant degree. They don't support joins, So instead of normalizing your data into a bunch of small parts, you're encouraged to embed the data into a single document. This creates a trade off where reads from a front end application are much faster. However, writing or updating data tends to be more complex. Document databases are far more general purpose than the other options we've looked at so far. From a developer perspective, they're very easy to use. They're often suitable for mobile games, IoT, content management, and many other use cases. If you're not exactly sure how your data is structured at this point, a document database is probably the best place to start. Where they generally fall short is when you have a lot of disconnected but related data that is updated often, like a social app that has many users who have many friends, who have many comments, who have many likes, and you wanna see all the comments that your friends like. Data like this needs to be joined, and it's not easily done in a document database at scale. Luckily, we have this thing that's been around forever called the relational database. You're likely familiar with this type of database with flavors like MySQL, Postgres, SQL Server, and many others. They've been around for nearly 50 years and continue to be one of the most popular types of databases in today's world. They were originally conceived by a computer scientist named Ted Codd. He worked for IBM and spent years working out his theories on relational data modeling. You can read his original paper online, and most of it goes way over my head. But you can appreciate the amount of math and science that went into the development of relational databases, and that's very likely why they remain so popular today. A few years later, this would inspire the development of SQL or Structured Query Language or SQL if you prefer. It's a special type of programming language called a query which that allows you to access and write data in the database. Okay. But what do we actually mean when we say relational database? Well, imagine you have a facility that builds airplanes. The facility is your database, and on that database, you might have different warehouses that hold different parts, like engines, wheels, and so on. Each warehouse is like a database table for holding a certain type of part. Each individual part has a serial number to uniquely identify it, and you can think of an individual part as a row in a table. So now that we have all these parts separated into different warehouses, how do we build an airplane? That's where relationships come in. We can build an airplane by referencing the unique ID of the different parts that go into it. Notice how each part has its own unique ID. This is known as its primary key, then it defines its various parts by referencing their IDs. These are known as foreign because they reference data in a different table. Now if we want to join all this data together, we can run a query to do that. So the main takeaway here is that an SQL database organizes data in its smallest normal form. However, a potential drawback here is that it requires a schema. If you don't know the right data shape upfront, they can be a little harder to work with. SQL databases are also ACID compliant, which means whenever there's a transaction in the database, Data validity is guaranteed even if there are network or hardware failures. That's essential for things like banks and financial institutions, but it makes this type of database inherently more difficult to scale. However, it's worth noting that there are modern SQL databases like Cockroach that are specifically designed to operate at scale. In any case, relational databases remain the most Popular type of database in production today. But what if instead of modeling a relationship in a schema, we just treated the relationship itself as data? Enter the graph database, where your data is represented as nodes and the relationships between them as edges. Popular options in this space include Neo 4J and d graph. Let's imagine we want to set up a many to many relationship in an SQL database. We do that by setting up a join table with the foreign keys that define the relationship. In a graph database, we don't need this middleman table. We just define an edge and connect it to the other record. We can now query this data with a statement that's much more concise and readable. In addition, we can achieve much better performance, especially on larger datasets. Graph databases can be a great alternative to SQL, especially if you're running a lot of joins and performance has taken a hit because of that. They're often used for fraud detection in finance, for building internal knowledge graphs within companies, and to power recommendation engines like the one used by Airbnb. Now let's imagine you want to build something like Google. A user provides a small amount of text, Then your database needs to return the most relevant results ranked in the proper order from a huge amount of data. For that, you're going to want a full text search engine. Most of the databases in this space are based on top of the Apache Lucene project, which has been around since 1999, like Solr and Elasticsearch. In addition, we have cloud based options like Algolia and my new personal favorite, Melee Search, a Rust based full text search engine. If you wanna check it out, I have a full tutorial on Fireship IO for Chrome members. From a developer perspective, they work very similar to a document oriented database. You start with an index, then you add a bunch of data objects to it. The difference is that under the hood, the search database will analyze all the text in the document and create an index of the searchable terms. So, essentially, it works just like the index that you would find in the back of a textbook. When a user performs a search, it only has to scan the index as opposed to every document in the database, and that makes it very fast even on large datasets. The database can also run a variety of different algorithms to rank those results, filter out irrelevant hits, handle typos, and so on. This does add a lot of overhead and they can be expensive to run at scale, but at the same time, they can add a ton of value to the user experience if you're building something like a type ahead search box. And with that, we've reached number 7, the multi model database, which in my opinion is the most exciting paradigm on this list. There are a few different options out there, but the database I want to focus on here is FaunaDB, which is very different than anything else we've looked at so far. If you're a front end developer, all you really care about is the data that you consume in the front end application. You just want some JSON. You don't wanna have to think about data modeling, schemas, replication, shards, or anything like that. With FaunaDB, you describe how you want to access your data using GraphQL. In this example, we have a user model and a post model, where a user can have many posts. If we upload our GraphQL scheme in a fauna, It automatically creates collections where we can store data and an index to query the data. Behind the scenes, it's figuring out how to take advantage of multiple database paradigms, like graph, relational, and document, and determining how to best use these paradigms based on the GraphQL code you provided. You create data by adding documents to collections, just like you would with a document database. But you're not stuck with the inherent limitations when it comes to data modeling. On top of that, it's ACID compliant, extremely fast, and you never have to worry about provisioning the actual infrastructure. You just decide how you wanna consume your data, and you let the cloud figure everything else out for you. I'm gonna go ahead and wrap things up there. We didn't cover every single database paradigm. There's a few others that you might wanna know about, like time series databases and also data warehouses. And if you wanna learn advanced data modeling concepts, consider becoming a pro member at FireShip IO and taking the Firestore data modeling like, course. Thanks for watching, and I will see you in the next one.
My
my
dad
dad
used
used
to
to
tell
tell
me,
me
use
use
the
the
right
right
tool
tool
for
for
the
the
job
job
and
and
not
not
vice
vice
versa.
versa
When
when
it
it
comes
comes
to
to
app
app
development,
development
choosing
choosing
the
the
right
right
database
database
is
is
one
one
of
of
the
the
single
single
most
most
important
important
decisions
decisions
that
that
you'll
you'll
ever
ever
make.
make
In
in
today's
today's
video,
video
we'll
we'll
look
look
at
at
7
7
different
different
database
database
paradigms,
paradigms
along
along
with
with
some
some
databases
databases
you've
you've
probably
probably
heard
heard
of
of
and
and
some
some
others
others
that
that
you
you
haven't.
haven't
We'll
we'll
look
look
at
at
how
how
they
they
work
work
from
from
a
a
technical
technical
perspective,
perspective
But
but
most
most
importantly,
importantly
we'll
we'll
try
try
to
to
understand
understand
what
what
they're
they're
best
best
used
used
for.
for
Because
because
my
my
dad
dad
also
also
used
used
to
to
tell
tell
me,
me
don't
don't
bring
bring
a
a
knife
knife
to
to
a
a
gunfight.
gunfight
If
if
you're
you're
new
new
here,
here
like
like
and
and
Subscribe.
subscribe
And
and
also
also
check
check
out
out
my
my
new
new
top
top
seven
seven
playlist
playlist
for
for
more
more
videos
videos
like
like
this.
this
Our
our
list
list
will
will
start
start
from
from
the
the
most
most
simple
simple
type
type
of
of
database
database
and
and
gradually
gradually
become
become
more
more
complex
complex
as
as
we
we
get
get
to
to
number
number
7.
7
And
and
that
that
brings
brings
us
us
to
to
our
our
first
first
paradigm,
paradigm
the
the
key
key
value
value
database.
database
Popular
popular
databases
databases
in
in
this
this
space
space
include
include
Redis,
redis
Memcached,
memcached
and
and
Etcd.
etcd
The
the
database
database
itself
itself
is
is
structured
structured
almost
almost
like
like
a
a
JavaScript
javascript
object
object
or
or
a
a
Python
python
dictionary.
dictionary
You
you
have
have
a
a
set
set
of
of
keys
keys
where
where
every
every
key
key
is
is
unique
unique
and
and
points
points
to
to
some
some
value.
value
In
in
Redis,
redis
for
for
example,
example
we
we
can
can
read
read
and
and
write
write
data
data
using
using
commands.
commands
We
we
use
use
the
the
set
set
command
command
followed
followed
by
by
a
a
key
key
and
and
a
a
value
value
to
to
write
write
data,
data
then
then
the
the
git
git
command
command
to
to
retrieve
retrieve
that
that
data
data
in
in
the
the
future.
future
In
in
the
the
case
case
of
of
Redis
redis
and
and
Memcached,
memcached
all
all
the
the
data
data
is
is
held
held
in
in
the
the
machine's
machine's
memory
memory
as
as
opposed
opposed
to
to
most
most
other
other
databases
databases
that
that
keep
keep
all
all
their
their
data
data
on
on
the
the
disk.
disk
This
this
limits
limits
the
the
amount
amount
of
of
data
data
you
you
can
can
store.
store
However,
however
it
it
makes
makes
the
the
database
database
extremely
extremely
fast
fast
because
because
it
it
doesn't
doesn't
require
require
a
a
round
round
trip
trip
to
to
the
the
disk
disk
for
for
every
every
operation.
operation
In
in
addition,
addition
it
it
doesn't
doesn't
perform
perform
queries,
queries
joins,
joins
or
or
anything
anything
like
like
that,
that
so
so
your
your
data
data
modeling
modeling
options
options
are
are
very
very
limited,
limited
but,
but
again,
again
it's
it's
extremely
extremely
fast,
fast
like
like
sub
sub
millisecond
millisecond
fast.
fast
You
you
wouldn't
wouldn't
wanna
wanna
use
use
a
a
key
key
value
value
store
store
for
for
your
your
main
main
app
app
data.
data
Most
most
often,
often
they're
they're
used
used
as
as
a
a
cache
cache
to
to
reduce
reduce
data
data
latency.
latency
Apps
apps
like
like
Twitter,
twitter
GitHub,
github
and
and
Snapchat
snapchat
I'll
i'll
use
use
Redis
redis
for
for
real
real
time
time
delivery
delivery
of
of
their
their
data.
data
There
there
are
are
other
other
use
use
cases
cases
beyond
beyond
caching,
caching
like
like
message
message
queues,
queues
pubsub,
pubsub
and
and
gaming
gaming
leaderboards,
leaderboards
But
but
more
more
often
often
than
than
not,
not
key
key
value
value
databases
databases
are
are
used
used
as
as
a
a
cache
cache
on
on
top
top
of
of
some
some
other
other
persistent
persistent
data
data
layer.
layer
Now
now
a
a
database
database
that
that
only
only
supports
supports
key
key
value
value
pairs
pairs
is
is
obviously
obviously
pretty
pretty
limited,
limited
And
and
that
that
brings
brings
us
us
to
to
the
the
wide
wide
column
column
database.
database
Popular
popular
options
options
in
in
this
this
family
family
include
include
Cassandra
cassandra
and
and
HBase.
hbase
A
a
wide
wide
column
column
database
database
is
is
like
like
you
you
took
took
a
a
key
key
value
value
database
database
and
and
added
added
a
a
second
second
dimension
dimension
to
to
it.
it
At
at
the
the
outer
outer
layer,
layer
you
you
have
have
a
a
key
key
space,
space
which
which
holds
holds
1
1
or
or
more
more
column
column
families,
families
and
and
each
each
column
column
family
family
holds
holds
a
a
set
set
of
of
ordered
ordered
rows.
rows
This
this
makes
makes
it
it
possible
possible
to
to
group
group
related
related
data
data
together.
together
But
but
unlike
unlike
a
a
relational
relational
database,
database
it
it
doesn't
doesn't
have
have
a
a
schema,
schema
so
so
it
it
can
can
handle
handle
unstructured
unstructured
data.
data
This
this
is
is
nice
nice
for
for
developers
developers
because
because
you
you
get
get
a
a
query
query
language
language
called
called
CQL
cql
that's
that's
very
very
similar
similar
to
to
SQL,
sql
although
although
much
much
more
more
limited
limited
and
and
you
you
can't
can't
do
do
joins.
joins
However,
however
it's
it's
much
much
easier
easier
to
to
scale
scale
up
up
and
and
replicate
replicate
data
data
across
across
multiple
multiple
nodes.
nodes
Unlike
unlike
an
an
SQL
sql
database,
database
it's
it's
decentralized
decentralized
and
and
can
can
scale
scale
horizontally.
horizontally
A
a
popular
popular
use
use
case
case
is
is
for
for
scaling
scaling
a
a
large
large
amount
amount
of
of
time
time
series
series
data,
data
like
like
records
records
from
from
an
an
IoT
iot
device,
device
weather
weather
sensors,
sensors
or
or
in
in
the
the
case
case
of
of
Netflix,
netflix
a
a
history
history
of
of
the
the
different
different
shows
shows
you've
you've
watched.
watched
It's
it's
often
often
used
used
in
in
situations
situations
where
where
you
you
have
have
frequent
frequent
writes
writes
but
but
infrequent
infrequent
updates
updates
and
and
reads.
reads
It's
it's
not
not
going
going
to
to
be
be
your
your
primary
primary
app
app
database.
database
For
for
that,
that
you'll
you'll
need
need
something
something
more
more
general
general
purpose,
purpose
like
like
a
a
document
document
oriented
oriented
database.
database
Popular
popular
options
options
in
in
the
the
document
document
family
family
include
include
MongoDB,
mongodb
Firestore,
firestore
DynamoDB,
dynamodb
CouchDB,
couchdb
and
and
a
a
few
few
others.
others
In
in
this
this
paradigm,
paradigm
you
you
have
have
documents,
documents
where
where
each
each
document
document
is
is
a
a
container
container
for
for
key
key
value
value
pairs.
pairs
They're
they're
unstructured
unstructured
and
and
don't
don't
require
require
a
a
schema,
schema
and
and
the
the
documents
documents
are
are
grouped
grouped
together
together
in
in
collections.
collections
Fields
fields
within
within
a
a
collection
collection
can
can
be
be
indexed,
indexed
And
and
collections
collections
can
can
be
be
organized
organized
into
into
a
a
logical
logical
hierarchy,
hierarchy
allowing
allowing
you
you
to
to
model
model
and
and
retrieve
retrieve
relational
relational
data
data
to
to
a
a
pretty
pretty
significant
significant
degree.
degree
They
they
don't
don't
support
support
joins,
joins
So
so
instead
instead
of
of
normalizing
normalizing
your
your
data
data
into
into
a
a
bunch
bunch
of
of
small
small
parts,
parts
you're
you're
encouraged
encouraged
to
to
embed
embed
the
the
data
data
into
into
a
a
single
single
document.
document
This
this
creates
creates
a
a
trade
trade
off
off
where
where
reads
reads
from
from
a
a
front
front
end
end
application
application
are
are
much
much
faster.
faster
However,
however
writing
writing
or
or
updating
updating
data
data
tends
tends
to
to
be
be
more
more
complex.
complex
Document
document
databases
databases
are
are
far
far
more
more
general
general
purpose
purpose
than
than
the
the
other
other
options
options
we've
we've
looked
looked
at
at
so
so
far.
far
From
from
a
a
developer
developer
perspective,
perspective
they're
they're
very
very
easy
easy
to
to
use.
use
They're
they're
often
often
suitable
suitable
for
for
mobile
mobile
games,
games
IoT,
iot
content
content
management,
management
and
and
many
many
other
other
use
use
cases.
cases
If
if
you're
you're
not
not
exactly
exactly
sure
sure
how
how
your
your
data
data
is
is
structured
structured
at
at
this
this
point,
point
a
a
document
document
database
database
is
is
probably
probably
the
the
best
best
place
place
to
to
start.
start
Where
where
they
they
generally
generally
fall
fall
short
short
is
is
when
when
you
you
have
have
a
a
lot
lot
of
of
disconnected
disconnected
but
but
related
related
data
data
that
that
is
is
updated
updated
often,
often
like
like
a
a
social
social
app
app
that
that
has
has
many
many
users
users
who
who
have
have
many
many
friends,
friends
who
who
have
have
many
many
comments,
comments
who
who
have
have
many
many
likes,
likes
and
and
you
you
wanna
wanna
see
see
all
all
the
the
comments
comments
that
that
your
your
friends
friends
like.
like
Data
data
like
like
this
this
needs
needs
to
to
be
be
joined,
joined
and
and
it's
it's
not
not
easily
easily
done
done
in
in
a
a
document
document
database
database
at
at
scale.
scale
Luckily,
luckily
we
we
have
have
this
this
thing
thing
that's
that's
been
been
around
around
forever
forever
called
called
the
the
relational
relational
database.
database
You're
you're
likely
likely
familiar
familiar
with
with
this
this
type
type
of
of
database
database
with
with
flavors
flavors
like
like
MySQL,
mysql
Postgres,
postgres
SQL
sql
Server,
server
and
and
many
many
others.
others
They've
they've
been
been
around
around
for
for
nearly
nearly
50
50
years
years
and
and
continue
continue
to
to
be
be
one
one
of
of
the
the
most
most
popular
popular
types
types
of
of
databases
databases
in
in
today's
today's
world.
world
They
they
were
were
originally
originally
conceived
conceived
by
by
a
a
computer
computer
scientist
scientist
named
named
Ted
ted
Codd.
codd
He
he
worked
worked
for
for
IBM
ibm
and
and
spent
spent
years
years
working
working
out
out
his
his
theories
theories
on
on
relational
relational
data
data
modeling.
modeling
You
you
can
can
read
read
his
his
original
original
paper
paper
online,
online
and
and
most
most
of
of
it
it
goes
goes
way
way
over
over
my
my
head.
head
But
but
you
you
can
can
appreciate
appreciate
the
the
amount
amount
of
of
math
math
and
and
science
science
that
that
went
went
into
into
the
the
development
development
of
of
relational
relational
databases,
databases
and
and
that's
that's
very
very
likely
likely
why
why
they
they
remain
remain
so
so
popular
popular
today.
today
A
a
few
few
years
years
later,
later
this
this
would
would
inspire
inspire
the
the
development
development
of
of
SQL
sql
or
or
Structured
structured
Query
query
Language
language
or
or
SQL
sql
if
if
you
you
prefer.
prefer
It's
it's
a
a
special
special
type
type
of
of
programming
programming
language
language
called
called
a
a
query
query
which
which
that
that
allows
allows
you
you
to
to
access
access
and
and
write
write
data
data
in
in
the
the
database.
database
Okay.
okay
But
but
what
what
do
do
we
we
actually
actually
mean
mean
when
when
we
we
say
say
relational
relational
database?
database
Well,
well
imagine
imagine
you
you
have
have
a
a
facility
facility
that
that
builds
builds
airplanes.
airplanes
The
the
facility
facility
is
is
your
your
database,
database
and
and
on
on
that
that
database,
database
you
you
might
might
have
have
different
different
warehouses
warehouses
that
that
hold
hold
different
different
parts,
parts
like
like
engines,
engines
wheels,
wheels
and
and
so
so
on.
on
Each
each
warehouse
warehouse
is
is
like
like
a
a
database
database
table
table
for
for
holding
holding
a
a
certain
certain
type
type
of
of
part.
part
Each
each
individual
individual
part
part
has
has
a
a
serial
serial
number
number
to
to
uniquely
uniquely
identify
identify
it,
it
and
and
you
you
can
can
think
think
of
of
an
an
individual
individual
part
part
as
as
a
a
row
row
in
in
a
a
table.
table
So
so
now
now
that
that
we
we
have
have
all
all
these
these
parts
parts
separated
separated
into
into
different
different
warehouses,
warehouses
how
how
do
do
we
we
build
build
an
an
airplane?
airplane
That's
that's
where
where
relationships
relationships
come
come
in.
in
We
we
can
can
build
build
an
an
airplane
airplane
by
by
referencing
referencing
the
the
unique
unique
ID
id
of
of
the
the
different
different
parts
parts
that
that
go
go
into
into
it.
it
Notice
notice
how
how
each
each
part
part
has
has
its
its
own
own
unique
unique
ID.
id
This
this
is
is
known
known
as
as
its
its
primary
primary
key,
key
then
then
it
it
defines
defines
its
its
various
various
parts
parts
by
by
referencing
referencing
their
their
IDs.
ids
These
these
are
are
known
known
as
as
foreign
foreign
because
because
they
they
reference
reference
data
data
in
in
a
a
different
different
table.
table
Now
now
if
if
we
we
want
want
to
to
join
join
all
all
this
this
data
data
together,
together
we
we
can
can
run
run
a
a
query
query
to
to
do
do
that.
that
So
so
the
the
main
main
takeaway
takeaway
here
here
is
is
that
that
an
an
SQL
sql
database
database
organizes
organizes
data
data
in
in
its
its
smallest
smallest
normal
normal
form.
form
However,
however
a
a
potential
potential
drawback
drawback
here
here
is
is
that
that
it
it
requires
requires
a
a
schema.
schema
If
if
you
you
don't
don't
know
know
the
the
right
right
data
data
shape
shape
upfront,
upfront
they
they
can
can
be
be
a
a
little
little
harder
harder
to
to
work
work
with.
with
SQL
sql
databases
databases
are
are
also
also
ACID
acid
compliant,
compliant
which
which
means
means
whenever
whenever
there's
there's
a
a
transaction
transaction
in
in
the
the
database,
database
Data
data
validity
validity
is
is
guaranteed
guaranteed
even
even
if
if
there
there
are
are
network
network
or
or
hardware
hardware
failures.
failures
That's
that's
essential
essential
for
for
things
things
like
like
banks
banks
and
and
financial
financial
institutions,
institutions
but
but
it
it
makes
makes
this
this
type
type
of
of
database
database
inherently
inherently
more
more
difficult
difficult
to
to
scale.
scale
However,
however
it's
it's
worth
worth
noting
noting
that
that
there
there
are
are
modern
modern
SQL
sql
databases
databases
like
like
Cockroach
cockroach
that
that
are
are
specifically
specifically
designed
designed
to
to
operate
operate
at
at
scale.
scale
In
in
any
any
case,
case
relational
relational
databases
databases
remain
remain
the
the
most
most
Popular
popular
type
type
of
of
database
database
in
in
production
production
today.
today
But
but
what
what
if
if
instead
instead
of
of
modeling
modeling
a
a
relationship
relationship
in
in
a
a
schema,
schema
we
we
just
just
treated
treated
the
the
relationship
relationship
itself
itself
as
as
data?
data
Enter
enter
the
the
graph
graph
database,
database
where
where
your
your
data
data
is
is
represented
represented
as
as
nodes
nodes
and
and
the
the
relationships
relationships
between
between
them
them
as
as
edges.
edges
Popular
popular
options
options
in
in
this
this
space
space
include
include
Neo
neo
4J
4j
and
and
d
d
graph.
graph
Let's
let's
imagine
imagine
we
we
want
want
to
to
set
set
up
up
a
a
many
many
to
to
many
many
relationship
relationship
in
in
an
an
SQL
sql
database.
database
We
we
do
do
that
that
by
by
setting
setting
up
up
a
a
join
join
table
table
with
with
the
the
foreign
foreign
keys
keys
that
that
define
define
the
the
relationship.
relationship
In
in
a
a
graph
graph
database,
database
we
we
don't
don't
need
need
this
this
middleman
middleman
table.
table
We
we
just
just
define
define
an
an
edge
edge
and
and
connect
connect
it
it
to
to
the
the
other
other
record.
record
We
we
can
can
now
now
query
query
this
this
data
data
with
with
a
a
statement
statement
that's
that's
much
much
more
more
concise
concise
and
and
readable.
readable
In
in
addition,
addition
we
we
can
can
achieve
achieve
much
much
better
better
performance,
performance
especially
especially
on
on
larger
larger
datasets.
datasets
Graph
graph
databases
databases
can
can
be
be
a
a
great
great
alternative
alternative
to
to
SQL,
sql
especially
especially
if
if
you're
you're
running
running
a
a
lot
lot
of
of
joins
joins
and
and
performance
performance
has
has
taken
taken
a
a
hit
hit
because
because
of
of
that.
that
They're
they're
often
often
used
used
for
for
fraud
fraud
detection
detection
in
in
finance,
finance
for
for
building
building
internal
internal
knowledge
knowledge
graphs
graphs
within
within
companies,
companies
and
and
to
to
power
power
recommendation
recommendation
engines
engines
like
like
the
the
one
one
used
used
by
by
Airbnb.
airbnb
Now
now
let's
let's
imagine
imagine
you
you
want
want
to
to
build
build
something
something
like
like
Google.
google
A
a
user
user
provides
provides
a
a
small
small
amount
amount
of
of
text,
text
Then
then
your
your
database
database
needs
needs
to
to
return
return
the
the
most
most
relevant
relevant
results
results
ranked
ranked
in
in
the
the
proper
proper
order
order
from
from
a
a
huge
huge
amount
amount
of
of
data.
data
For
for
that,
that
you're
you're
going
going
to
to
want
want
a
a
full
full
text
text
search
search
engine.
engine
Most
most
of
of
the
the
databases
databases
in
in
this
this
space
space
are
are
based
based
on
on
top
top
of
of
the
the
Apache
apache
Lucene
lucene
project,
project
which
which
has
has
been
been
around
around
since
since
1999,
1999
like
like
Solr
solr
and
and
Elasticsearch.
elasticsearch
In
in
addition,
addition
we
we
have
have
cloud
cloud
based
based
options
options
like
like
Algolia
algolia
and
and
my
my
new
new
personal
personal
favorite,
favorite
Melee
melee
Search,
search
a
a
Rust
rust
based
based
full
full
text
text
search
search
engine.
engine
If
if
you
you
wanna
wanna
check
check
it
it
out,
out
I
i
have
have
a
a
full
full
tutorial
tutorial
on
on
Fireship
fireship
IO
io
for
for
Chrome
chrome
members.
members
From
from
a
a
developer
developer
perspective,
perspective
they
they
work
work
very
very
similar
similar
to
to
a
a
document
document
oriented
oriented
database.
database
You
you
start
start
with
with
an
an
index,
index
then
then
you
you
add
add
a
a
bunch
bunch
of
of
data
data
objects
objects
to
to
it.
it
The
the
difference
difference
is
is
that
that
under
under
the
the
hood,
hood
the
the
search
search
database
database
will
will
analyze
analyze
all
all
the
the
text
text
in
in
the
the
document
document
and
and
create
create
an
an
index
index
of
of
the
the
searchable
searchable
terms.
terms
So,
so
essentially,
essentially
it
it
works
works
just
just
like
like
the
the
index
index
that
that
you
you
would
would
find
find
in
in
the
the
back
back
of
of
a
a
textbook.
textbook
When
when
a
a
user
user
performs
performs
a
a
search,
search
it
it
only
only
has
has
to
to
scan
scan
the
the
index
index
as
as
opposed
opposed
to
to
every
every
document
document
in
in
the
the
database,
database
and
and
that
that
makes
makes
it
it
very
very
fast
fast
even
even
on
on
large
large
datasets.
datasets
The
the
database
database
can
can
also
also
run
run
a
a
variety
variety
of
of
different
different
algorithms
algorithms
to
to
rank
rank
those
those
results,
results
filter
filter
out
out
irrelevant
irrelevant
hits,
hits
handle
handle
typos,
typos
and
and
so
so
on.
on
This
this
does
does
add
add
a
a
lot
lot
of
of
overhead
overhead
and
and
they
they
can
can
be
be
expensive
expensive
to
to
run
run
at
at
scale,
scale
but
but
at
at
the
the
same
same
time,
time
they
they
can
can
add
add
a
a
ton
ton
of
of
value
value
to
to
the
the
user
user
experience
experience
if
if
you're
you're
building
building
something
something
like
like
a
a
type
type
ahead
ahead
search
search
box.
box
And
and
with
with
that,
that
we've
we've
reached
reached
number
number
7,
7
the
the
multi
multi
model
model
database,
database
which
which
in
in
my
my
opinion
opinion
is
is
the
the
most
most
exciting
exciting
paradigm
paradigm
on
on
this
this
list.
list
There
there
are
are
a
a
few
few
different
different
options
options
out
out
there,
there
but
but
the
the
database
database
I
i
want
want
to
to
focus
focus
on
on
here
here
is
is
FaunaDB,
faunadb
which
which
is
is
very
very
different
different
than
than
anything
anything
else
else
we've
we've
looked
looked
at
at
so
so
far.
far
If
if
you're
you're
a
a
front
front
end
end
developer,
developer
all
all
you
you
really
really
care
care
about
about
is
is
the
the
data
data
that
that
you
you
consume
consume
in
in
the
the
front
front
end
end
application.
application
You
you
just
just
want
want
some
some
JSON.
json
You
you
don't
don't
wanna
wanna
have
have
to
to
think
think
about
about
data
data
modeling,
modeling
schemas,
schemas
replication,
replication
shards,
shards
or
or
anything
anything
like
like
that.
that
With
with
FaunaDB,
faunadb
you
you
describe
describe
how
how
you
you
want
want
to
to
access
access
your
your
data
data
using
using
GraphQL.
graphql
In
in
this
this
example,
example
we
we
have
have
a
a
user
user
model
model
and
and
a
a
post
post
model,
model
where
where
a
a
user
user
can
can
have
have
many
many
posts.
posts
If
if
we
we
upload
upload
our
our
GraphQL
graphql
scheme
scheme
in
in
a
a
fauna,
fauna
It
it
automatically
automatically
creates
creates
collections
collections
where
where
we
we
can
can
store
store
data
data
and
and
an
an
index
index
to
to
query
query
the
the
data.
data
Behind
behind
the
the
scenes,
scenes
it's
it's
figuring
figuring
out
out
how
how
to
to
take
take
advantage
advantage
of
of
multiple
multiple
database
database
paradigms,
paradigms
like
like
graph,
graph
relational,
relational
and
and
document,
document
and
and
determining
determining
how
how
to
to
best
best
use
use
these
these
paradigms
paradigms
based
based
on
on
the
the
GraphQL
graphql
code
code
you
you
provided.
provided
You
you
create
create
data
data
by
by
adding
adding
documents
documents
to
to
collections,
collections
just
just
like
like
you
you
would
would
with
with
a
a
document
document
database.
database
But
but
you're
you're
not
not
stuck
stuck
with
with
the
the
inherent
inherent
limitations
limitations
when
when
it
it
comes
comes
to
to
data
data
modeling.
modeling
On
on
top
top
of
of
that,
that
it's
it's
ACID
acid
compliant,
compliant
extremely
extremely
fast,
fast
and
and
you
you
never
never
have
have
to
to
worry
worry
about
about
provisioning
provisioning
the
the
actual
actual
infrastructure.
infrastructure
You
you
just
just
decide
decide
how
how
you
you
wanna
wanna
consume
consume
your
your
data,
data
and
and
you
you
let
let
the
the
cloud
cloud
figure
figure
everything
everything
else
else
out
out
for
for
you.
you
I'm
i'm
gonna
gonna
go
go
ahead
ahead
and
and
wrap
wrap
things
things
up
up
there.
there
We
we
didn't
didn't
cover
cover
every
every
single
single
database
database
paradigm.
paradigm
There's
there's
a
a
few
few
others
others
that
that
you
you
might
might
wanna
wanna
know
know
about,
about
like
like
time
time
series
series
databases
databases
and
and
also
also
data
data
warehouses.
warehouses
And
and
if
if
you
you
wanna
wanna
learn
learn
advanced
advanced
data
data
modeling
modeling
concepts,
concepts
consider
consider
becoming
becoming
a
a
pro
pro
member
member
at
at
FireShip
fireship
IO
io
and
and
taking
taking
the
the
Firestore
firestore
data
data
modeling
modeling
like,
like
course.
course
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The use of database paradigms is broadly discussed, with key value databases and wide column databases being common examples. A Doctorate database is recommended for scaling large amounts of time series data, but not for smaller datasets. The multi-mission database, FaunaDB, is discussed, and a tutorial on creating a single model database is provided. The Doctorate database is ACID compliant and allows for updates and reads, but is not as popular for smaller datasets. The speaker also discusses the use of graph databases and their benefits, including being ACID compliant and being a front end developer.
7 Database Paradigms
My dad used to tell me, use the right tool for the job and not vice versa. When it comes to app development, choosing the right database is one of the single most important decisions that you'll ever make. In today's video, we'll look at 7 different database paradigms, along with some databases you've probably heard of and some others that you haven't. We'll look at how they work from a technical perspective, But most importantly, we'll try to understand what they're best used for. Because my dad also used to tell me, don't bring a knife to a gunfight. If you're new here, like and Subscribe. And also check out my new top seven playlist for more videos like this. Our list will start from the most simple type of database and gradually become more complex as we get to number 7. And that brings us to our first paradigm, the key value database. Popular databases in this space include Redis, Memcached, and Etcd. The database itself is structured almost like a JavaScript object or a Python dictionary. You have a set of keys where every key is unique and points to some value. In Redis, for example, we can read and write data using commands. We use the set command followed by a key and a value to write data, then the git command to retrieve that data in the future. In the case of Redis and Memcached, all the data is held in the machine's memory as opposed to most other databases that keep all their data on the disk. This limits the amount of data you can store. However, it makes the database extremely fast because it doesn't require a round trip to the disk for every operation. In addition, it doesn't perform queries, joins, or anything like that, so your data modeling options are very limited, but, again, it's extremely fast, like sub millisecond fast. You wouldn't wanna use a key value store for your main app data. Most often, they're used as a cache to reduce data latency. Apps like Twitter, GitHub, and Snapchat I'll use Redis for real time delivery of their data. There are other use cases beyond caching, like message queues, pubsub, and gaming leaderboards, But more often than not, key value databases are used as a cache on top of some other persistent data layer. Now a database that only supports key value pairs is obviously pretty limited, And that brings us to the wide column database. Popular options in this family include Cassandra and HBase. A wide column database is like you took a key value database and added a second dimension to it. At the outer layer, you have a key space, which holds 1 or more column families, and each column family holds a set of ordered rows. This makes it possible to group related data together. But unlike a relational database, it doesn't have a schema, so it can handle unstructured data. This is nice for developers because you get a query language called CQL that's very similar to SQL, although much more limited and you can't do joins. However, it's much easier to scale up and replicate data across multiple nodes. Unlike an SQL database, it's decentralized and can scale horizontally. A popular use case is for scaling a large amount of time series data, like records from an IoT device, weather sensors, or in the case of Netflix, a history of the different shows you've watched. It's often used in situations where you have frequent writes but infrequent updates and reads. It's not going to be your primary app database. For that, you'll need something more general purpose, like a document oriented database. Popular options in the document family include MongoDB, Firestore, DynamoDB, CouchDB, and a few others. In this paradigm, you have documents, where each document is a container for key value pairs. They're unstructured and don't require a schema, and the documents are grouped together in collections. Fields within a collection can be indexed, And collections can be organized into a logical hierarchy, allowing you to model and retrieve relational data to a pretty significant degree. They don't support joins, So instead of normalizing your data into a bunch of small parts, you're encouraged to embed the data into a single document. This creates a trade off where reads from a front end application are much faster. However, writing or updating data tends to be more complex. Document databases are far more general purpose than the other options we've looked at so far. From a developer perspective, they're very easy to use. They're often suitable for mobile games, IoT, content management, and many other use cases. If you're not exactly sure how your data is structured at this point, a document database is probably the best place to start. Where they generally fall short is when you have a lot of disconnected but related data that is updated often, like a social app that has many users who have many friends, who have many comments, who have many likes, and you wanna see all the comments that your friends like. Data like this needs to be joined, and it's not easily done in a document database at scale. Luckily, we have this thing that's been around forever called the relational database. You're likely familiar with this type of database with flavors like MySQL, Postgres, SQL Server, and many others. They've been around for nearly 50 years and continue to be one of the most popular types of databases in today's world. They were originally conceived by a computer scientist named Ted Codd. He worked for IBM and spent years working out his theories on relational data modeling. You can read his original paper online, and most of it goes way over my head. But you can appreciate the amount of math and science that went into the development of relational databases, and that's very likely why they remain so popular today. A few years later, this would inspire the development of SQL or Structured Query Language or SQL if you prefer. It's a special type of programming language called a query which that allows you to access and write data in the database. Okay. But what do we actually mean when we say relational database? Well, imagine you have a facility that builds airplanes. The facility is your database, and on that database, you might have different warehouses that hold different parts, like engines, wheels, and so on. Each warehouse is like a database table for holding a certain type of part. Each individual part has a serial number to uniquely identify it, and you can think of an individual part as a row in a table. So now that we have all these parts separated into different warehouses, how do we build an airplane? That's where relationships come in. We can build an airplane by referencing the unique ID of the different parts that go into it. Notice how each part has its own unique ID. This is known as its primary key, then it defines its various parts by referencing their IDs. These are known as foreign because they reference data in a different table. Now if we want to join all this data together, we can run a query to do that. So the main takeaway here is that an SQL database organizes data in its smallest normal form. However, a potential drawback here is that it requires a schema. If you don't know the right data shape upfront, they can be a little harder to work with. SQL databases are also ACID compliant, which means whenever there's a transaction in the database, Data validity is guaranteed even if there are network or hardware failures. That's essential for things like banks and financial institutions, but it makes this type of database inherently more difficult to scale. However, it's worth noting that there are modern SQL databases like Cockroach that are specifically designed to operate at scale. In any case, relational databases remain the most Popular type of database in production today. But what if instead of modeling a relationship in a schema, we just treated the relationship itself as data? Enter the graph database, where your data is represented as nodes and the relationships between them as edges. Popular options in this space include Neo 4J and d graph. Let's imagine we want to set up a many to many relationship in an SQL database. We do that by setting up a join table with the foreign keys that define the relationship. In a graph database, we don't need this middleman table. We just define an edge and connect it to the other record. We can now query this data with a statement that's much more concise and readable. In addition, we can achieve much better performance, especially on larger datasets. Graph databases can be a great alternative to SQL, especially if you're running a lot of joins and performance has taken a hit because of that. They're often used for fraud detection in finance, for building internal knowledge graphs within companies, and to power recommendation engines like the one used by Airbnb. Now let's imagine you want to build something like Google. A user provides a small amount of text, Then your database needs to return the most relevant results ranked in the proper order from a huge amount of data. For that, you're going to want a full text search engine. Most of the databases in this space are based on top of the Apache Lucene project, which has been around since 1999, like Solr and Elasticsearch. In addition, we have cloud based options like Algolia and my new personal favorite, Melee Search, a Rust based full text search engine. If you wanna check it out, I have a full tutorial on Fireship IO for Chrome members. From a developer perspective, they work very similar to a document oriented database. You start with an index, then you add a bunch of data objects to it. The difference is that under the hood, the search database will analyze all the text in the document and create an index of the searchable terms. So, essentially, it works just like the index that you would find in the back of a textbook. When a user performs a search, it only has to scan the index as opposed to every document in the database, and that makes it very fast even on large datasets. The database can also run a variety of different algorithms to rank those results, filter out irrelevant hits, handle typos, and so on. This does add a lot of overhead and they can be expensive to run at scale, but at the same time, they can add a ton of value to the user experience if you're building something like a type ahead search box. And with that, we've reached number 7, the multi model database, which in my opinion is the most exciting paradigm on this list. There are a few different options out there, but the database I want to focus on here is FaunaDB, which is very different than anything else we've looked at so far. If you're a front end developer, all you really care about is the data that you consume in the front end application. You just want some JSON. You don't wanna have to think about data modeling, schemas, replication, shards, or anything like that. With FaunaDB, you describe how you want to access your data using GraphQL. In this example, we have a user model and a post model, where a user can have many posts. If we upload our GraphQL scheme in a fauna, It automatically creates collections where we can store data and an index to query the data. Behind the scenes, it's figuring out how to take advantage of multiple database paradigms, like graph, relational, and document, and determining how to best use these paradigms based on the GraphQL code you provided. You create data by adding documents to collections, just like you would with a document database. But you're not stuck with the inherent limitations when it comes to data modeling. On top of that, it's ACID compliant, extremely fast, and you never have to worry about provisioning the actual infrastructure. You just decide how you wanna consume your data, and you let the cloud figure everything else out for you. I'm gonna go ahead and wrap things up there. We didn't cover every single database paradigm. There's a few others that you might wanna know about, like time series databases and also data warehouses. And if you wanna learn advanced data modeling concepts, consider becoming a pro member at FireShip IO and taking the Firestore data modeling like, course. Thanks for watching, and I will see you in the next one.
The use of database paradigms is broadly discussed, with key value databases and wide column databases being common examples. A Doctorate database is recommended for scaling large amounts of time series data, but not for smaller datasets. The multi-mission database, FaunaDB, is discussed, and a tutorial on creating a single model database is provided. The Doctorate database is ACID compliant and allows for updates and reads, but is not as popular for smaller datasets. The speaker also discusses the use of graph databases and their benefits, including being ACID compliant and being a front end developer.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : 7 Database Paradigms 
        and a small summary : The use of database paradigms is broadly discussed, with key value databases and wide column databases being common examples. A Doctorate database is recommended for scaling large amounts of time series data, but not for smaller datasets. The multi-mission database, FaunaDB, is discussed, and a tutorial on creating a single model database is provided. The Doctorate database is ACID compliant and allows for updates and reads, but is not as popular for smaller datasets. The speaker also discusses the use of graph databases and their benefits, including being ACID compliant and being a front end developer.
        [/INST]
        
        Generate the video : My dad used to tell me, use the right tool for the job and not vice versa. When it comes to app development, choosing the right database is one of the single most important decisions that you'll ever make. In today's video, we'll look at 7 different database paradigms, along with some databases you've probably heard of and some others that you haven't. We'll look at how they work from a technical perspective, But most importantly, we'll try to understand what they're best used for. Because my dad also used to tell me, don't bring a knife to a gunfight. If you're new here, like and Subscribe. And also check out my new top seven playlist for more videos like this. Our list will start from the most simple type of database and gradually become more complex as we get to number 7. And that brings us to our first paradigm, the key value database. Popular databases in this space include Redis, Memcached, and Etcd. The database itself is structured almost like a JavaScript object or a Python dictionary. You have a set of keys where every key is unique and points to some value. In Redis, for example, we can read and write data using commands. We use the set command followed by a key and a value to write data, then the git command to retrieve that data in the future. In the case of Redis and Memcached, all the data is held in the machine's memory as opposed to most other databases that keep all their data on the disk. This limits the amount of data you can store. However, it makes the database extremely fast because it doesn't require a round trip to the disk for every operation. In addition, it doesn't perform queries, joins, or anything like that, so your data modeling options are very limited, but, again, it's extremely fast, like sub millisecond fast. You wouldn't wanna use a key value store for your main app data. Most often, they're used as a cache to reduce data latency. Apps like Twitter, GitHub, and Snapchat I'll use Redis for real time delivery of their data. There are other use cases beyond caching, like message queues, pubsub, and gaming leaderboards, But more often than not, key value databases are used as a cache on top of some other persistent data layer. Now a database that only supports key value pairs is obviously pretty limited, And that brings us to the wide column database. Popular options in this family include Cassandra and HBase. A wide column database is like you took a key value database and added a second dimension to it. At the outer layer, you have a key space, which holds 1 or more column families, and each column family holds a set of ordered rows. This makes it possible to group related data together. But unlike a relational database, it doesn't have a schema, so it can handle unstructured data. This is nice for developers because you get a query language called CQL that's very similar to SQL, although much more limited and you can't do joins. However, it's much easier to scale up and replicate data across multiple nodes. Unlike an SQL database, it's decentralized and can scale horizontally. A popular use case is for scaling a large amount of time series data, like records from an IoT device, weather sensors, or in the case of Netflix, a history of the different shows you've watched. It's often used in situations where you have frequent writes but infrequent updates and reads. It's not going to be your primary app database. For that, you'll need something more general purpose, like a document oriented database. Popular options in the document family include MongoDB, Firestore, DynamoDB, CouchDB, and a few others. In this paradigm, you have documents, where each document is a container for key value pairs. They're unstructured and don't require a schema, and the documents are grouped together in collections. Fields within a collection can be indexed, And collections can be organized into a logical hierarchy, allowing you to model and retrieve relational data to a pretty significant degree. They don't support joins, So instead of normalizing your data into a bunch of small parts, you're encouraged to embed the data into a single document. This creates a trade off where reads from a front end application are much faster. However, writing or updating data tends to be more complex. Document databases are far more general purpose than the other options we've looked at so far. From a developer perspective, they're very easy to use. They're often suitable for mobile games, IoT, content management, and many other use cases. If you're not exactly sure how your data is structured at this point, a document database is probably the best place to start. Where they generally fall short is when you have a lot of disconnected but related data that is updated often, like a social app that has many users who have many friends, who have many comments, who have many likes, and you wanna see all the comments that your friends like. Data like this needs to be joined, and it's not easily done in a document database at scale. Luckily, we have this thing that's been around forever called the relational database. You're likely familiar with this type of database with flavors like MySQL, Postgres, SQL Server, and many others. They've been around for nearly 50 years and continue to be one of the most popular types of databases in today's world. They were originally conceived by a computer scientist named Ted Codd. He worked for IBM and spent years working out his theories on relational data modeling. You can read his original paper online, and most of it goes way over my head. But you can appreciate the amount of math and science that went into the development of relational databases, and that's very likely why they remain so popular today. A few years later, this would inspire the development of SQL or Structured Query Language or SQL if you prefer. It's a special type of programming language called a query which that allows you to access and write data in the database. Okay. But what do we actually mean when we say relational database? Well, imagine you have a facility that builds airplanes. The facility is your database, and on that database, you might have different warehouses that hold different parts, like engines, wheels, and so on. Each warehouse is like a database table for holding a certain type of part. Each individual part has a serial number to uniquely identify it, and you can think of an individual part as a row in a table. So now that we have all these parts separated into different warehouses, how do we build an airplane? That's where relationships come in. We can build an airplane by referencing the unique ID of the different parts that go into it. Notice how each part has its own unique ID. This is known as its primary key, then it defines its various parts by referencing their IDs. These are known as foreign because they reference data in a different table. Now if we want to join all this data together, we can run a query to do that. So the main takeaway here is that an SQL database organizes data in its smallest normal form. However, a potential drawback here is that it requires a schema. If you don't know the right data shape upfront, they can be a little harder to work with. SQL databases are also ACID compliant, which means whenever there's a transaction in the database, Data validity is guaranteed even if there are network or hardware failures. That's essential for things like banks and financial institutions, but it makes this type of database inherently more difficult to scale. However, it's worth noting that there are modern SQL databases like Cockroach that are specifically designed to operate at scale. In any case, relational databases remain the most Popular type of database in production today. But what if instead of modeling a relationship in a schema, we just treated the relationship itself as data? Enter the graph database, where your data is represented as nodes and the relationships between them as edges. Popular options in this space include Neo 4J and d graph. Let's imagine we want to set up a many to many relationship in an SQL database. We do that by setting up a join table with the foreign keys that define the relationship. In a graph database, we don't need this middleman table. We just define an edge and connect it to the other record. We can now query this data with a statement that's much more concise and readable. In addition, we can achieve much better performance, especially on larger datasets. Graph databases can be a great alternative to SQL, especially if you're running a lot of joins and performance has taken a hit because of that. They're often used for fraud detection in finance, for building internal knowledge graphs within companies, and to power recommendation engines like the one used by Airbnb. Now let's imagine you want to build something like Google. A user provides a small amount of text, Then your database needs to return the most relevant results ranked in the proper order from a huge amount of data. For that, you're going to want a full text search engine. Most of the databases in this space are based on top of the Apache Lucene project, which has been around since 1999, like Solr and Elasticsearch. In addition, we have cloud based options like Algolia and my new personal favorite, Melee Search, a Rust based full text search engine. If you wanna check it out, I have a full tutorial on Fireship IO for Chrome members. From a developer perspective, they work very similar to a document oriented database. You start with an index, then you add a bunch of data objects to it. The difference is that under the hood, the search database will analyze all the text in the document and create an index of the searchable terms. So, essentially, it works just like the index that you would find in the back of a textbook. When a user performs a search, it only has to scan the index as opposed to every document in the database, and that makes it very fast even on large datasets. The database can also run a variety of different algorithms to rank those results, filter out irrelevant hits, handle typos, and so on. This does add a lot of overhead and they can be expensive to run at scale, but at the same time, they can add a ton of value to the user experience if you're building something like a type ahead search box. And with that, we've reached number 7, the multi model database, which in my opinion is the most exciting paradigm on this list. There are a few different options out there, but the database I want to focus on here is FaunaDB, which is very different than anything else we've looked at so far. If you're a front end developer, all you really care about is the data that you consume in the front end application. You just want some JSON. You don't wanna have to think about data modeling, schemas, replication, shards, or anything like that. With FaunaDB, you describe how you want to access your data using GraphQL. In this example, we have a user model and a post model, where a user can have many posts. If we upload our GraphQL scheme in a fauna, It automatically creates collections where we can store data and an index to query the data. Behind the scenes, it's figuring out how to take advantage of multiple database paradigms, like graph, relational, and document, and determining how to best use these paradigms based on the GraphQL code you provided. You create data by adding documents to collections, just like you would with a document database. But you're not stuck with the inherent limitations when it comes to data modeling. On top of that, it's ACID compliant, extremely fast, and you never have to worry about provisioning the actual infrastructure. You just decide how you wanna consume your data, and you let the cloud figure everything else out for you. I'm gonna go ahead and wrap things up there. We didn't cover every single database paradigm. There's a few others that you might wanna know about, like time series databases and also data warehouses. And if you wanna learn advanced data modeling concepts, consider becoming a pro member at FireShip IO and taking the Firestore data modeling like, course. Thanks for watching, and I will see you in the next one.
        