Overview

This report details the performance evaluation of two distinct database architectures—Amazon Aurora Serverless v2 and Provisioned RDS (db.r8gd family)—within a multi-tenant FOLIO environment. The objective of this testing phase is to benchmark system stability, scalability, and response times under production-like traffic conditions. Specifically, the evaluation aims to compare the elasticity of Serverless v2 against the consistent performance baseline of provisioned r8gd instances, assessing their ability to handle both "Common Day" and "Worst Day" production load(SMCH) patterns across 20 concurrent tenants.

Ticket: PERF-1424: Perform tests to compare performance with Serverless and high loadClosedPreview

Summary:

1. Under Common Day load, Aurora Serverless v2 demonstrated better overall performance than the Provisioned r8gd.4xl, delivering consistently lower p90 latencies for heavy inventory operations and authentication workflows. While both architectures processed similar throughput, Serverless v2 proved more efficient at maintaining stable response times and mitigating latency degradation.

2. Test 6 was deliberately executed to evaluate the lower bounds of DB by downscaling to a db.r8gd.2xl instance under Common Day load. As anticipated, the architecture failed to sustain the 20-tenant concurrency. Severe database memory starvation resulted in a critically high error rate and triggered cascading module restarts, confirming that a 2xlarge instance is strictly insufficient for this baseline workload.

3. Under Worst Day load conditions, both Aurora Serverless v2 and Provisioned db.r8gd.4xl successfully sustained operations with comparable total throughput. Aurora Serverless demonstrated stronger resilience during heavy I/O tasks, yielding lower p90 latencies for critical inventory operations (e.g., GET inventory items at 4.50s vs 5.15s, and GET inventory instance at 20.95s vs 21.71s). Both architectures proved highly capable of absorbing peak traffic spikes without systemic degradation.

4. Although the load profile was escalated from Common Day to Worst Day, we did not observe a corresponding increase in overall throughput. To address this bottleneck, we scaled the ECS cluster by allocating 4 tasks to critical modules (mod-inventory, mod-inventory-storage, mod-source-record-manager, and mod-source-record-storage). This infrastructure tuning successfully unblocked the system, increasing total throughput from 1.9k RPS to 2.2k RPS.

5. Comparing the standard Provisioned db.r8gd.4xl architecture (Test 4) against the identical database configuration paired with a scaled ECS cluster (Test 5) reveals performance improvements under Worst Day load conditions. The ECS tuning eliminated application-level bottlenecks for heavy workflows. Most notably, response times for the critical GET inventory instance operations plummeted from an average of ~17.1s down to ~3.7s, with 90th percentile (p90) latency dropping from 21.71s to 5.67s (a ~74% reduction).

Recommendations & Jiras

• EUREKA-902: Optimize high-frequency SQL query on user_tenant table inIn RefinementPreview

• Permanently scale mod-inventory, mod-inventory-storage, mod-source-record-manager, and mod-source-record-storage to 4 ECS tasks to prevent application-level compute bottlenecks. Testing confirmed this infrastructure tuning is essential, as it successfully unblocks processing constraints and increases overall system throughput from 1.9k to 2.2k RPS.

• Previous report:
  PTF-Test Hybrid DB Deployment on multiple(30) tenants[Galileo environment]. Provision DB + Serverless V2. Part 2 ,
  PTF-Test Hybrid DB Deployment on multiple tenants[Galileo environment]. Provisioned primary DB db.r7g.2xlarge paired with Dedicated Offload DB db.r8g.2xlarg. Part 3,
  PTF-Test Hybrid DBDeployment on multiple tenants[Galileo enviroment].
  
  

Test runs 

Test results

Response time tables

Test 1, 2 - Common day production load

Test 3, Test 4 and Test 5 - Worst day production load