Skip to main content
Version: 3.6 (unsupported)
    Features and pricing

    Set up a database for ScalarDB/ScalarDL deployment on AWS

    This guide explains how to set up a database for ScalarDB/ScalarDL deployment on AWS.

    Amazon DynamoDB​

    Authentication method​

    When you use DynamoDB, you must set REGION, ACCESS_KEY_ID, and SECRET_ACCESS_KEY in the ScalarDB/ScalarDL properties file as follows.

    scalar.db.contact_points=<REGION>
    scalar.db.username=<ACCESS_KEY_ID>
    scalar.db.password=<SECRET_ACCESS_KEY>
    scalar.db.storage=dynamo

    Please refer to the following document for more details on the properties for DynamoDB.

    Required configuration/steps​

    DynamoDB is available for use in AWS by default. You do not need to set up anything manually to use it.

    Optional configurations/steps​

    You can enable PITR as a backup/restore method for DynamoDB. If you use ScalarDB Schema Loader for creating schema, it enables the PITR feature for tables by default. Please refer to the official document for more details.

    It is recommended since the point-in-time recovery feature automatically and continuously takes backups so that you can reduce downtime (pause duration) for backup operations. Please refer to the following document for more details on how to backup/restore Scalar product data.

    You can configure the monitoring and logging of DynamoDB using its native feature. Please refer to the official document for more details.

    It is recommended since the metrics and logs help you to investigate some issues in the production environment when they happen.

    // Note that We have not yet tested this feature with Scalar products.
    // TODO: We need to test this feature with Scalar products.

    It is recommended since the private internal connections not via WAN can make a system more secure.

    Configure Read/Write Capacity (Optional based on your environment)​

    You can configure the Read/Write Capacity of DynamoDB tables based on your requirements. Please refer to the official document for more details on Read/Write Capacity.

    You can configure Read/Write Capacity using ScalarDB/DL Schema Loader when you create a table. Please refer to the following document for more details on how to configure Read/Write Capacity (RU) using ScalarDB/DL Schema Loader.

    Amazon RDS for MySQL, PostgreSQL, Oracle, and SQL Server​

    Authentication method​

    When you use RDS, you must set JDBC_URL, USERNAME, and PASSWORD in the ScalarDB/ScalarDL properties file as follows.

    scalar.db.contact_points=<JDBC_URL>
    scalar.db.username=<USERNAME>
    scalar.db.password=<PASSWORD>
    scalar.db.storage=jdbc

    Please refer to the following document for more details on the properties for RDS (JDBC databases).

    Required configuration/steps​

    Create an RDS database instance​

    You must create an RDS database instance. Please refer to the official document for more details.

    Optional configurations/steps​

    You can enable automated backups. Please refer to the official document for more details.

    It is recommended since the automated backups feature enables a point-in-time recovery feature. It can recover data to a specific point in time. It can reduce downtime (pause duration) for backup operations when you use multi databases under Scalar products. Please refer to the following document for more details on how to backup/restore the Scalar product data.

    You can configure the monitoring and logging of RDS using its native feature. Please refer to the official documents for more details.

    It is recommended since the metrics and logs help you to investigate some issues in the production environment when they happen.

    Public access is disabled by default. You can access the RDS database instance from the Scalar product pods on your EKS cluster as follows.

    • Create the RDS database instance on the same VPC as your EKS cluster.
    • Connect the VPC for the RDS and the VPC for the EKS cluster for the Scalar product deployment using VPC peering. (// TODO: We need to test this feature with Scalar products.)

    It is recommended since the private internal connections not via WAN can make a system more secure.

    Amazon Aurora MySQL and Amazon Aurora PostgreSQL​

    Authentication method​

    When you use Amazon Aurora, you must set JDBC_URL, USERNAME, and PASSWORD in the ScalarDB/ScalarDL properties file as follows.

    scalar.db.contact_points=<JDBC_URL>
    scalar.db.username=<USERNAME>
    scalar.db.password=<PASSWORD>
    scalar.db.storage=jdbc

    Please refer to the following document for more details on the properties for Amazon Aurora (JDBC databases).

    Required configuration/steps​

    Create an Amazon Aurora DB cluster​

    You must create an Amazon Aurora DB cluster. Please refer to the official document for more details.

    Optional configurations/steps​

    Configure backup configurations (Optional based on your environment)​

    Amazon Aurora automatically gets a backup by default. You do not need to enable the backup feature manually.

    If you want to change some backup configurations like the backup retention period and backup window, you can configure them. Please refer to the official document for more details.

    Please refer to the following document for more details on how to backup/restore the Scalar product data.

    You can configure the monitoring and logging of Amazon Aurora using its native feature. Please refer to the official documents for more details.

    It is recommended since the metrics and logs help you to investigate some issues in the production environment when they happen.

    Public access is disabled by default. You can access the Amazon Aurora DB cluster from the Scalar product pods on your EKS cluster as follows.

    • Create the Amazon Aurora DB cluster on the same VPC as your EKS cluster.
    • Connect the VPC for the Amazon Aurora DB cluster and the VPC for the EKS cluster for the Scalar product deployment using VPC peering. (// TODO: We need to test this feature with Scalar products.)

    It is recommended since the private internal connections not via WAN can make a system more secure.