AWS Aurora Serverless v2: Architecture, Features, Pricing, and Comparison with Fauna

Aurora’s design philosophy

Aurora’s architecture

Routing layer

Query layer

Storage layer

• Loss of two partition copies in different AZs does not have user-facing impact
• Loss of two partition copies in the same AZ will affect latency and may require a primary process failover to another AZ to mitigate, but the database will remain available for writes
• Loss of three partition copies will make the database unavailable for writes, but will not cause data loss
• Loss of four or more partition copies makes the database completely unavailable and may lose data

Aurora's original scaling model

Scalability improvements in Aurora Serverless v2

• Buffer pool flushes and copies
• Connection resets
• Cancellation of long-running queries

Fauna’s architecture

1. Fauna has a separate transaction log service, which ensures data consistency while maintaining horizontal scalability and high availability
2. Fauna is programmable, with a rich standard library of functions. It can run transactional business computation adjacent to the data and let the developer compose computational logic in a maintainable way
3. Fauna has a dynamic multi-tenancy model, instead of process-based provisioning
4. Fauna uses stateless, secure HTTP connections directly, instead of via translation
5. Fauna is natively temporal, which means it tracks document and schema history and makes it available for querying within the query languages themselves

Routing layer

Query layer

Log layer

• Horizontal scalability for writes
• A predictable latency profile for writes (in a global configuration, less than 150ms)
• Very low latency for consistent reads (less than 10ms regardless of topology), eliminating the need to worry about eventual consistency

Storage layer

Serverlessness and query isolation

In Fauna

• There is no minimum capacity requirement per database
• Databases that aren’t being actively queried consume no resources, aside from storage
• There is no maximum capacity limit per database
• Every database is always highly available in every region, regardless of previous query locality
• The developer is freed from having to manage capacity and locality

In Aurora Serverless v2

• The database cannot effectively quiesce, because starting a new database process takes approximately 30 seconds, timing out any requests issued in the process. The alternative, to keep an idle process running, wastes resources.
• Scaling a process up is fast, as long as there are machine-local resources that can be added to the process’s host VM. But scaling down requires releasing memory, connections, and threads. In particular, releasing memory requires dropping part of the cache.
• Similar to scaling up, scaling out by adding new read processes on new VMs is straightforward, barring cold start time, but scaling back in may be blocked until long-running queries complete.
• Because scale-down is computationally costly, Aurora limits scaledown events to approximately every 30 seconds. This means that a single query can incur 30 seconds of provisioned time regardless of need, and a burst of queries could push the vertical scale high enough that many 30 second cooldown cycles are required to bring capacity back to baseline. Similar to the scale-to-zero issue, this can waste significant resources.
• The dimensions of capacity are not continuous. Query performance varies as scale changes due to the combination of vertical and horizontal scaling across individual read and write processes.

Multi-tenancy and operational isolation

• It requires using the AWS API from within the application to create new customer databases, instead of SQL, leading to a host of new security concerns
• It adds an additional dimension of physical isolation that interacts very poorly with Aurora’s scalability model

Comparing Fauna’s developer experience with Aurora

• Fauna doesn’t require connection pooling
• Fauna doesn’t require cache management
• Fauna doesn’t require capacity planning
• Fauna doesn’t require a minimum capacity to avoid cold start latency
• Fauna doesn’t require a special security perimeter--it is secure for access over the public internet, and integrates with third-party web identity providers

• Fauna’s GraphQL and FQL query APIs fit modern application development patterns without the use of middleware
• Fauna is always transactional and consistent, no matter where and how it is queried
• Fauna offers streaming built-in, not through a second system
• Fauna offers database management via FQL, not via a separate operational API
• Fauna has built-in temporality
• Fauna supports the database-per-customer pattern for SaaS applications

Aurora serverless pricing, explained

Minimum costs

• The minimum current running cost is 4 ACUs: $0.48 per hour or $350 per month
• The minimum scalability increment is 30 seconds of runtime for a half-ACU, or $0.0005 (this means there is a possible worst-case cost of $500 per million transactions for workloads that pathologically trigger the auto-scaling function)

Compute capacity

    BEGIN;
    UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
    SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
    UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
    UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
    INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
    END;

Let({
  account: Get(Ref(Collection('accounts'), '13')),
  teller: Get(Ref(Collection('tellers'), '19')),
  branch: Get(Ref(Collection('branches'), '17'))
},
  Do(
    Update(Select(['ref'], Var('account')), Add(Select(['balance'], Var('account')), 500)),
    Update(Select(['ref'], Var('account')), Add(Select(['balance'], Var('teller')), 500)),
    Update(Select(['ref'], Var('account')), Add(Select(['balance'], Var('branch')), 500)),
    Create(Collection('history'), { data: { 
        aid: Ref(Collection('accounts'), '13'),
        tid: Ref(Collection('accounts'), '19'),
        bid: Ref(Collection('accounts'), '17'),
        delta: 500
        // transaction time is recorded automatically 
      }}
    )
  )
)

IO costs

Multi-region replication costs

Storage costs

Bandwidth costs

Miscellaneous other costs

Conclusion