Forge SQL is now available as part of our Early Access Program (EAP).

Forge SQL is an experimental feature offered to selected users for testing and feedback purposes. This feature is unsupported and subject to change without notice. Do not use Forge SQL in apps that handle sensitive information (including personally identifiable information) and customer data.

For more details, see Forge EAP, Preview, and GA.

Forge SQL (EAP)

We are currently working on a Forge SQL capability that will let you use an SQL database for your app. Forge SQL will provision and host your app’s database (and by extension, store your customer’s app data) on Atlassian infrastructure.

Forge SQL provisions a single database instance per installation. That is, each instance will be associated to a specific installation of your app. As a result, each app installation will have its own dedicated database instance, storing only data specific to that installation.

Tutorial: Using Forge SQL

Start testing Forge SQL's available capabilities by registering for our EAP. Refer to our tutorial for instructions.

Explore tutorial

Registration

You can start testing Forge SQL’s available capabilities by registering for our EAP. For instructions, see the Forge SQL tutorial.

Limitations

Forge SQL offers a multi-tenant SQL solution offering tenant isolation and stable query performance. To do so, we add a few constraints over and above TiDB’s limitations:

Foreign keys are not supported.
Each READ operation has a 5 second timeout configured.
Forge SQL API (for non-READ statements) will timeout after 10 seconds of execution.
Each QUERY operation has a memory quota set to 8 MB.
Within each minute, all concurrent invocations share a total query execution time of 250 seconds (per installation).
Each SQL statement can only contain a single query.

EAP limitations

During this EAP, you’ll be able to use Forge SQL to manually provision an SQL database instance accessible to your app. For now, this will only be allowed on sites in your development environment. After provisioning your database instance, you can start building your database schema by writing and executing SQL migration.

The following table describes other EAP limitations of Forge SQL, and how they’ll change over time:

Limitation	Future plan
You’ll need to define event triggers to provision an SQL database instance for your app when it’s installed.	Forge SQL will automatically provision a database instance for your app upon installation.
You’ll need to define a web trigger to run your app’s SQL migration scripts.	Forge SQL may offer different mechanism(s) to allow app developers to apply schema changes across databases.
SQL operations executed while tunneling will be directed to the provisioned database on the site where the app is installed.	While tunneling, you’ll be able to specify whether SQL operations should be directed to your provisioned database or a local one.
Data residency is not supported.	Upon full release, data stored in Forge SQL can be pinned to a region and migrated between regions (like data in other forms of Forge hosted storage).
By default, Forge SQL provisions all databases in `us-west-2`. If you are testing from another region, let us know through the EAP thread on the Atlassian Developer Community so we can route your SQL requests in a latency-sensitive manner	Upon full release, Forge SQL will automatically provision databases in the same region as the customer's site.

For this EAP, we will restrict each installation to a fixed number of concurrent connections and a connection queue depth. We may adjust these limits as needed to tune Forge SQL's performance during the EAP.

Atlassian will delete all provisioned SQL databases (along with all data they contain) within 30 days after the end of the EAP period.

Implementation

Forge SQL is based on a MYSQL-compliant, distributed SQL database. We've configured Forge SQL to comply with standard ANSI-compliant SQL. To allow for optimal data portability outcomes, we strongly encourage you use standard ANSI SQL syntax when interacting with the database.

Forge SQL is currently based on a self-hosted TiDB implementation, and we impose limitations on how the database can be used to support Forge use cases.

We recommend that you avoid designing applications with TiDb-specific functionality.

Monitoring

Forge SQL provides reliability and latency metrics to help you understand your app’s database interactions. To view these metrics:

Access the developer console.
Select your Forge app that you want to view metrics for.
Select Metrics in the left menu.
Select SQL in the left menu.

At this time, the developer console can provide metrics on HTTP response status codes and response times. For more details about available SQL metrics, see Monitor SQL metrics.