Purpose-Built Database Selection

Selection is the Professional skill

SAP-C02 Task 2.5 is less “name every database” and more choose the engine whose data model matches the access pattern. AWS’s June 2026 Choosing an AWS database service decision guide frames OLTP catalogs (relational and non-relational) separately from Amazon Redshift, which exists for online analytical processing (OLAP). The AWS Well-Architected Framework performance pillar makes the same point: use a purpose-built data store rather than one monolithic database.

Independent SAP-C02 study material by OpenExamPrep uses that published methodology. It does not claim OpenExamPrep is an AWS partner or that this guide is an official blueprint substitute.

Work the stem in order:

1. Data model — rows and joins, key-value, JSON documents, graph edges, wide-column, time series, vectors, or logs.
2. Access — single-item lookup, range query, multi-hop traversal, full-text search, or warehouse aggregation.
3. Consistency and latency — ACID multi-row, single-digit milliseconds, microseconds, or eventually consistent analytics.
4. Residency and scale — one Region Multi-AZ, active-active Regions, or petabyte scans.
5. Operations — managed versus self-hosted, serverless versus provisioned.
6. Migration reality — re-platform to RDS, refactor to Aurora or DynamoDB, or (rarely) rehost on EC2.

Usually more than one database appears in a correct architecture. AWS’s own ecommerce example mixes DocumentDB (catalog), DynamoDB (browse latency), and Aurora (inventory and orders). Northwind Payments should look the same: several purpose-built stores, not one Oracle on EC2 “for simplicity.”

Relational OLTP: RDS engines versus Aurora

Amazon Relational Database Service (Amazon RDS) is the managed path when you need a conventional engine with automated backups, patching, and Multi-AZ deployments. RDS engines are PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, and Db2. Pick RDS when the stem requires Oracle, SQL Server, MariaDB, or Db2, or when the team must stay on a specific RDS feature set.

Amazon Aurora (MySQL-compatible and PostgreSQL-compatible) is the usual upgrade when the workload is relational OLTP and those two compatibilities are enough. You gain the shared cluster volume, typically sub-minute failover with readers, and Global Database. Aurora is not a drop-in for Oracle PL/SQL or SQL Server T-SQL. If Northwind’s core settlement system is still Oracle-specific, RDS for Oracle (or a stated migration off Oracle) is the honest answer—not “put it on Aurora PostgreSQL” without a conversion story.

Newer catalog entries such as Amazon Aurora DSQL and Aurora PostgreSQL Limitless Database exist in the 2026 decision guide (distributed SQL and sharded PostgreSQL). SAP-C02 still uses a three-month generally available gate before new features appear as scored items. Treat them as current AWS options to confirm against that rule, not as a reason to ignore classic Aurora clusters on this exam series.

Document, graph, wide-column, time series

Amazon DocumentDB (with MongoDB compatibility) stores JSON-like documents with rich queries across fields. Northwind’s merchant catalog (nested hours, terminals, and fee schedules that differ by merchant) is a document problem. It is not a reason to shred JSON into hundreds of RDS tables unless the stem demands relational constraints.

Amazon Neptune is the graph database for networks of objects: social graphs, fraud detection, and recommendations. Northwind’s fraud team does not want to JOIN seven SQL tables to ask “which cards share devices with this merchant and then paid at a second high-risk merchant?” Neptune is optimized to traverse relationships with low latency. That is the graph-fraud scenario on this exam: edges and multi-hop patterns, not a warehouse star schema and not a DynamoDB single-key lookup.

Amazon Keyspaces (for Apache Cassandra) is wide-column and Cassandra-compatible. Use it to migrate Cassandra or for heavy read/write tables that need single-digit millisecond latency and linear scale. Do not pick Keyspaces because a stem said “wide table” if the workload is actually relational reporting.

Amazon Timestream is the time series service for Internet of Things (IoT) data, application metrics, and asset tracking. Northwind’s terminals emit temperature, connectivity, and decline-rate points every few seconds. That telemetry is timestamped, high ingest, and queried as trends—not as a row-level payment authorization. Keep authorizations on Aurora or DynamoDB; land the time-series IoT stream on Timestream. Read the availability change before you design: AWS closed new customer access to Amazon Timestream for LiveAnalytics effective 20 June 2025 and tells new customers to evaluate Amazon Timestream for InfluxDB instead, while existing customers with an active payer account continue as normal. Timestream is still on the SAP-C02 in-scope service list, so it remains the exam-correct time-series answer; in a 2026 greenfield design, name the Timestream engine the account can actually onboard. Forcing billions of sensor points into Aurora bloats the OLTP volume and still yields a poor time-series engine.

Redshift is OLAP, not the authorization database

Amazon Redshift is a managed columnar warehouse with massively parallel processing. AWS states it is designed for OLAP and business intelligence: aggregations, scans, and joins on large historical sets. PostgreSQL-compatible SQL does not make it an OLTP engine. Redshift omits OLTP-oriented behaviors (for example, it does not rely on the same secondary-index and single-row DML profile as PostgreSQL) so analytic scans run well.

Northwind’s CFO dashboard that groups yearly interchange by country belongs on Redshift (often loaded from Aurora or S3). The authorization that must commit in milliseconds does not. A common pattern AWS describes: RDS or Aurora for the application, AWS Glue or AWS Database Migration Service to move data into Redshift. If a stem asks where to run the nightly rollup, Redshift. If it asks where to record the capture, Aurora or RDS.

ElastiCache is a cache, not a system of record

Amazon ElastiCache (Valkey, Memcached, Redis OSS; serverless or node-based) is an ephemeral in-memory cache for microsecond reads and sub-millisecond writes of frequently accessed data. The decision guide is explicit: use it to improve read performance, not to replace the database.

Northwind may cache merchant fee schedules or session tokens in ElastiCache in front of DynamoDB or Aurora. If a node is replaced or a cache is flushed, the system of record (SoR) must still have the data. If the stem requires persistence with sub-millisecond reads as a primary database, look at Amazon MemoryDB, not ElastiCache. The in-memory caching chapter of this guide goes deeper on engine choice; this section only locks the SoR versus cache boundary that Task 2.5 database selection depends on.

Trap: “put the ledger in Redis so it is fast.” Speed without durability and backup/restore semantics is not a payments architecture.

OpenSearch is search and analytics

Amazon OpenSearch Service deploys OpenSearch (or legacy Elasticsearch OSS up to 7.10) for log analytics, monitoring, clickstream, full-text search, and vector/k-NN retrieval. DynamoDB, DocumentDB, and other stores often stream or zero-ETL into OpenSearch. That does not make OpenSearch the cardholder data environment.

Northwind indexes authorization error logs and merchant-portal search in OpenSearch. Investigators still pull the signed ledger from Aurora. Mixing those roles is a distractor: “store settlements in OpenSearch so we can search them.”

Self-managed on EC2 is the wrong default

The decision guide’s rehost path is honest: install the engine on Amazon EC2, migrate data, and keep operating the way you did on premises. You still own upgrades, patches, backups, capacity, performance, and availability. Re-platform to RDS, or refactor to Aurora, DynamoDB, Neptune, or DocumentDB, removes that undifferentiated work.

On SAP-C02, EC2 as the database host is justified when the stem forces it: an engine or extension RDS/Aurora do not offer, OS-level agents the compliance team will not move, or a short-term rehost with an explicit later modernization. “We always control the OS” is not a Professional default when Keyspaces, Timestream, Neptune, or RDS already match the data model.

Northwind should not run self-managed Cassandra on EC2 when Keyspaces exists, self-managed MongoDB when DocumentDB exists, or a single-AZ MySQL on EC2 when Aurora Multi-AZ exists—unless the item states a constraint those services cannot meet.

Putting the four scenarios in one company

Northwind’s map:

• Global payments / ledger: Aurora (often Global Database) or RDS if the engine must be Oracle or SQL Server.
• Session store: DynamoDB Global Tables, optional Regional DAX, ElastiCache only as a cache.
• Graph fraud: Neptune for device-card-merchant rings; do not fake this with Redshift or a heroic SQL recursion.
• Time-series IoT: Timestream for terminal telemetry; do not park it in the OLTP cluster.

Add DocumentDB if the catalog is document-shaped, Keyspaces if Cassandra is already the standard, OpenSearch for logs and search, Redshift for BI. That is purpose-built design. One EC2 database for all four is the answer you eliminate first.

Selection traps

1. Using Redshift for row-level authorizations because it “speaks SQL.”
2. Using ElastiCache as the only copy of session or payment data.
3. Using OpenSearch as the settlement system of record.
4. Using Aurora for multi-hop fraud graphs.
5. Using Neptune for time-series IoT.
6. Using Timestream for ACID settlement.
7. Defaulting to self-managed EC2 whenever the company already has DBAs.
8. Forcing every JSON payload into RDS third-normal-form when DocumentDB matches the queries.
9. Telling a brand-new AWS customer in 2026 to onboard Timestream for LiveAnalytics as if the 20 June 2025 availability change had not happened, instead of naming Timestream for InfluxDB.