This guide explains how to cache database data using PolyScale in conjunction with an application running on Fly.io.
Read on for more details related to working with PolyScale on Fly.
PolyScale on Fly sits outside of PolyScale’s default global edge network and hence to connect via your Fly app, a different hostname is used:
Due to the ephemeral nature of Fly’s network, Fly does not provide static outbound IP’s that are guaranteed not to change. This mandates that your database be publicly accessible.
PolyScale on Fly can work with any of the supported databases from any database provider.
Postgres on Fly
If you are running a database on Fly, you must assign a publicly available IP address to that database to be accessible via PolyScale.
PolyScale on Fly Network
At launch, PolyScale has PoPs running on the following Fly locations:
- Seattle (SEA)
- Virginia (IAD)
- Amsterdam (AMS)
- Singapore (SIN)
Our network is continuously growing based on customer demand, so please contact us if you would like to request an additional location. We can deploy a new PoP in a few hours.
Step 1: Create PolyScale Cache
Before creating a PolyScale cache, make sure you have your current database host and port credentials, as you will need them to set up PolyScale.
- In your PolyScale account, click on the New Cache button
- Give the cache a Name
- Select the Type of database you have
- Enter the Host address for your existing database
- Enter the Port used for your existing database
- Click Create
When you create your cache, PolyScale will automatically run a network test to ensure it can make a TCP connection to your database from the global PolyScale edge network regions. If you see any locations that cannot connect, this indicates that you have not configured your database for public network access.
You now have a working database cache configured.
Step 2: Connect to your PolyScale Cache
To connect to the origin database via PolyScale simply update any client applications as follows:
Step 2.1: Use a PolyScale database hostname and port:
Using your PolyScale cache is simple -- instead of connecting to your database directly, you'll replace your original host with the PolyScale on Fly host -
In the PolyScale user interface, the host will show as
psedge.global. Do not use this host with Fly. Any applications running on Fly must use the
fly.psedge.global host in order to ensure correct routing.
Depending on your database type, select the appropriate port choice below.
- SQL Server
Step 2.2: Provide a PolyScale Cache ID as part of the connection string:
The Cache ID tells PolyScale where to route your database traffic, and as such must be passed as part of your connection URI.
The Cache ID can be found under the
Settings tab of any cache (as detailed in Step 2 above). For MySQL, MariaDB and SQL Server, this is prepended to the database username separated with a hyphen. For PostgreSQL, an
application_name property containing the PolyScale Cache ID is required as part of the connection string e.g.
For further details, see Getting Connected.
Step 2.3: Update your Fly environment variables
Typically, your database credentials for Fly are stored in an environment variable (usually as
DATABASE_URL), using the full database Connection URI, which includes your username, password, host, port and database name. To connect your PolyScale cache, simply update the value for your
DATABASE_URL environment variable to use the PolyScale connection URI (making the changes indicated in Step 2.1 and Step 2.2 above) in place of your original.
You can always find the PolyScale connection URI on the Connect tab for your PolyScale cache. Copy this string, and insert your USERNAME, PASSWORD, and DATABASE name in the indicated places. Also be sure to use the
fly.psedge.global host in place of
Your Fly environment variables can be set using the Fly CLI:
fly secrets set DATABASE_URL=“postgres://[DBUSER]:[DBPASSWORD]@fly.psedge.global:5432/[DBNAME]?application_name=[CACHEID]”
That's it. Now your Fly application is connected to PolyScale. Database queries will be automatically cached (unless manually configured otherwise) to speed up query execution times and lower network latency.