Aurora
Last updated: Sep 23, 2026
Rationale
Amazon Aurora is the service we use for relational databases in the cloud. We run its PostgreSQL-compatible edition in Serverless v2 mode for the workloads that need SQL, while DynamoDB remains the database for the platform's business data.
The main reasons why we chose it over other alternatives are:
- It is a fully managed service. Patching, replication, failover and storage growth are handled by AWS, so there are no database servers to operate.
- It complies with several certifications from ISO and CSA. Many of these certifications are focused on ensuring that the entity follows best practices regarding secure cloud-based environments and information security.
- It supports Serverless v2 scaling, which lets each cluster grow and shrink between a minimum and a maximum capacity based on load, and pause to zero capacity when it is idle. Clusters that only receive traffic from scheduled jobs consume no compute in between.
- It exposes the RDS Data API, an HTTPS interface that lets Lambda functions run SQL statements without keeping database connections open.
- It supports IAM database authentication, allowing us to grant each workload access to a specific database user from its IAM role, with short-lived tokens instead of stored passwords.
- It integrates with AWS Secrets Manager to generate and rotate the master password, so no human ever handles it.
- It supports encryption at rest with KMS and can be configured to reject connections that do not use TLS.
- It provides continuous backups with point-in-time recovery, final snapshots on deletion and deletion protection, reducing the chance of losing data by mistake.
- It exports PostgreSQL logs to CloudWatch and supports Performance Insights and enhanced monitoring, giving us visibility into slow queries and resource usage.
- It can export cluster data to S3 in Parquet format, which is how we copy tables into Snowflake without adding load to the database.
- Resources can be written as code using Terraform. All our clusters are created by the same in-house Terraform module, so every one of them gets the same security and operational baseline.
Alternatives
No alternatives are currently being considered, as Aurora is the managed relational database within AWS, where the rest of our infrastructure lives, and the workloads that do not need SQL already run on DynamoDB and Snowflake.
Usage
We use Amazon Aurora PostgreSQL Serverless v2 for three clusters:
- Storing the advisory database built by Aggregates, our Software Composition Analysis database builder. A Batch job synchronizes the advisories, reachability templates and package versions into the cluster, and the public vulnerability database website queries it in real time.
- Storing the audit and usage events collected by Tracks, the audit logging service behind Platform audit logs. Events arrive through an SQS queue and a Lambda consumer writes them using the RDS Data API.
- Storing the git commit history ingested by the code ETL of Observes, which is the system of record for the authors the platform bills. The platform reads it through IAM database authentication, and a daily export to S3 feeds the billing tables in Snowflake.
We do not use Amazon Aurora for:
- Storing the platform's business data, which lives in DynamoDB.
- Analytics and reporting, which run on Snowflake.