The Problem with Traditional Databases
Think of a traditional database like a filing cabinet bolted to a specific desk. If that desk breaks, you lose access to all your files. To protect yourself, you'd need to buy a second desk, bolt a second cabinet to it, and manually keep both cabinets in sync — a slow, expensive, error-prone process. Traditional relational databases like MySQL or PostgreSQL, when deployed on a single server, work exactly this way. Compute (the CPU doing SQL processing) and storage (the disk holding your data) are physically coupled. High availability required complex, manually configured replication between servers, and failover was measured in minutes.
Amazon Aurora is a fully managed relational database engine that is wire-compatible with MySQL and PostgreSQL — meaning your existing application code, drivers, and SQL queries work without modification. But under the hood, Aurora is architecturally different from anything that came before it in the managed database space. It was designed from scratch for the cloud, not ported from an on-premises model.
The Key Innovation: Separation of Compute and Storage. Aurora completely decouples the SQL processing engine (Compute) from the disk storage layer (Storage). The compute nodes run your queries. The storage layer — a purpose-built, distributed storage system — handles durability, replication, and self-healing entirely on its own. The compute nodes don't manage replication; they simply write log records and let the storage layer figure out the rest. This separation is what enables Aurora's most powerful capabilities: instant failover, self-healing storage, and up to 15 read replicas that all share the same underlying data without copying it.
The architectural consequence of this separation is profound: adding a read replica in Aurora takes minutes, not hours, because there is no data to copy. The new replica simply connects to the same shared storage volume that the writer already uses.