Database

A database organizes information so that applications can retrieve and change it reliably. A database management system provides the software that processes queries, controls concurrent access, and enforces supported integrity rules. Although engineers often use “database” to mean both the stored data and the system managing it, a database is not simply a storage volume or a collection of files: its defining value is how it organizes and manages access to information.

Database selection starts with the data model and access patterns. Relational databases organize data into tables and support relationships, SQL queries, and transactions. For example, an ordering application can use a transaction to create an order and update inventory together. Key-value databases retrieve records by key and suit predictable lookups, such as retrieving a shopping cart by customer identifier. Document databases store document-shaped records, while graph databases represent relationships that applications need to traverse. No single model is best for every workload.

In the cloud, engineers can install database software on virtual machines or use managed database services. Self-management provides more operating-system and software control but requires responsibility for patching, backups, replication, and recovery. Managed services automate selected operational tasks, with the exact responsibilities varying by service. Customers still own data classification, access permissions, application query design, and appropriate configuration. Serverless database options further reduce capacity management, but they still have limits, configuration choices, and usage charges.

Transactional and analytical workloads have different requirements. An online checkout needs short, predictable reads and writes against current records. A reporting platform may scan millions of historical transactions to calculate trends. A data warehouse is optimized for analytical queries rather than serving as a universal replacement for an operational database. Similarly, an in-memory cache can accelerate repeated reads, but cached values may expire or become stale; it should not automatically be treated as the authoritative record.

Availability, durability, and recovery are separate concerns. Replication can support failover, while read replicas can increase read capacity where supported. Replication does not replace backups because accidental deletion or corruption can propagate to replicas. Engineers should define acceptable data loss and recovery time, configure suitable backups, and test restoration. For Amazon RDS, a traditional Multi-AZ DB instance deployment primarily provides high availability; its standby does not serve application reads. Other RDS deployment types have different read capabilities.

Scaling also involves trade-offs. Larger instances can provide more resources, while partitioning and additional replicas can distribute suitable workloads. Indexes accelerate selected queries but consume storage and add write overhead. Distributed systems may expose different consistency options, so applications must understand when a read can return an older value. NoSQL does not mean “no transactions,” and managed does not mean “no administration.”

For AWS service-identification questions, match requirements to database capabilities. Amazon RDS provides managed relational databases, and Amazon Aurora is a relational engine compatible with MySQL or PostgreSQL. Amazon DynamoDB supports key-value and document workloads. Amazon DocumentDB provides MongoDB compatibility, Amazon Neptune supports graph workloads, Amazon ElastiCache provides managed in-memory caching, and Amazon Redshift supports data warehousing and analytics. Compatibility should not be assumed to mean identical features or unrestricted application portability.