Databases in the Cloud

The 2 a.m. problem a managed database solves

A database crashes at 2 a.m. Someone has to notice, diagnose whether it was a bad patch, a disk failure, or a runaway query, and bring it back without losing data. Running a database yourself, even on a cloud virtual machine, means that someone is you. A managed database service exists to make that someone the provider instead, for everything except the parts only you can answer, like which queries your application actually runs.

What "managed" actually takes over

Amazon RDS is the model for a managed relational database, and its own documentation is specific about the split. Compare running a database on-premises, on a plain EC2 virtual machine, and on RDS:

Moving from on-premises to EC2 hands over the physical hardware. Moving from EC2 to RDS hands over almost everything about running the database engine itself, patching, backups, scaling, failure detection and recovery. What stays with you in every column is query tuning, because that depends entirely on your specific application, your specific queries, and your specific data, work no managed service can do on your behalf.

Relational databases: rows that relate to other rows

Picture an online store's Orders table. Every row needs a customer_id that points to a real row in a separate Customers table, and a product_id that points to a real row in Inventory. That enforced relationship, an order that cannot exist without a matching customer and product, is the defining feature of a relational database: data organized into tables with rows and columns, queried with SQL, and connected across tables through keys. Amazon RDS supports 6 engines this way: MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, Oracle Database, and IBM Db2, all queryable with the same relational model even though the underlying engines differ.

That structure is exactly what an order needs. If a payment fails partway through checkout, the database must not leave an order pointing at a customer or inventory row that no longer makes sense, and relational databases are built to enforce that kind of consistency.

NoSQL databases: fast lookups without the relationships

Now picture a leaderboard for a game with 10 million concurrent players, or a shopping cart that gets read and rewritten on every click. Neither one needs to be joined against another table, and neither one benefits from the overhead of enforcing table relationships. NoSQL databases, modeled on Amazon DynamoDB, drop the table-and-join model in favor of items retrieved directly by a key, with a flexible structure that can differ from one item to the next. DynamoDB advertises single-digit millisecond performance whether an application serves tens of thousands or hundreds of millions of concurrent users, because the entire design trades away cross-item relationships for that kind of scale.

The boundary: match the model to the access pattern

Worked example: 1 platform, 2 databases

The same e-commerce platform from the previous lesson needs both models at once, not a single choice between them. Orders, customers, and inventory go in a relational database, because an order that references a nonexistent customer or an inventory row is a bug, and the relational model is what prevents it. Shopping cart contents and session data go in a NoSQL database, because that data changes constantly, gets read on nearly every page load, and never needs to be joined against the Orders table to do its job. Running both side by side, rather than forcing every kind of data through one model, is normal architecture, not a compromise.

The misconception: newer does not mean universally better

It is tempting to treat NoSQL as the modern upgrade and relational as the legacy option. That framing misses what each one actually gives up. NoSQL scales to enormous concurrent load precisely because it does not enforce relationships between items, the exact guarantee an order-and-inventory system depends on. A well-run application does not pick a side once, it puts each kind of data in the model built for its access pattern, which is why real systems commonly run relational and NoSQL databases side by side rather than choosing one for everything.

Where this leaves you

A managed database service takes over patching, backups, and failure recovery so you can focus on the queries and the schema only you understand. Reach for a relational database when records must stay consistent with each other across tables, and reach for NoSQL when the workload is a high-volume, simple lookup that does not need those relationships. The next lesson covers how traffic actually reaches these databases and the compute in front of them: cloud networking.