So we've talked a lot about when to select a spreadsheet and when not to, but let's actually dive into a little more practically, how do you select the right database and how can you get started on that path from a practical perspective? As we get started, just know that Cloud Academy's content library has a lot, and I mean a lot, of highly detailed information about the specifics of specific database technologies. And I know I said specific twice there, but they really do have a lot of in-depth content.

So if this introduction and practical guide isn't enough and you are really facing specific problems, search for the exact database you're using on Cloud Academy, and you'll be able to find highly detailed instructions. But to dive into here, by far the most common type of database is known as a relational database. These relational databases are what most people think of traditionally as a database.

Their history goes way back, and they are typically what people refer to just in passing when they refer to a database, unless you're having a more technical discussion. The most popular ones are MySQL, PostgreSQL, and SQLServer. These are legacy databases that go way back. They also continue innovation, so they're still used in cutting edge applications today.

They're used in business applications that require structured data. This means that the data is representable in terms of tables, columns, and rows, so they're a little similar to spreadsheets in that regard. But very importantly, if you're looking at a relational database, you're thinking in terms of structured data, the data is highly repeatable, highly predictable. You know what's coming in and you're able to apply control to it. They're also able to handle extremely large amounts of volume relative to a spreadsheet.

Although, if there's anybody on this course listening in, they don't quite scale up to what a distributed system could mean. I would say a traditional rule of thumb is if you have less than a handful of terabytes of data, the single relational databases are key for you, PostgreSQL, SQL and MySQL. Amazon, in particular, can handle up to 64 terabyte MySQL databases now through what they call their Aurora platform. As a rule of thumb though, if you start to get above single-digit terabytes, it's time to start considering more advanced technologies

The other major category of databases is known as NoSQL. This convenient name doesn't mean negative sequel. It actually means Not only SQL. These are databases that you've probably actually already come across. They're classics such as MongoDB or CouchDB. And some of the more big data databases in this space might be HBase or Google Bigtable. These databases are really designed for high volume, high-performance applications, but there's a very important twist. They don't require you to have the data in a tabular format. This is very important because it means that the data can come in as any real schema without you needing to predefine it. This is not to say there's no schema at all, but this is what you want if you have a high flexibility in your data.

Typically, the best way to use these is in what we call a key-value pair where you have some type of key like user ID and some type of value such as user preferences. I personally have used this type of database when handling highly unstructured test data coming from a production environment where they're building new IoT devices and onboarding new sensors.

So to quickly recap right there is SQL is typically good for structured data that you know what's coming in and you want to have enforced expressible relationships. And NoSQL is really ideal for when you have data that's coming in with variable formats and structures.