https://planetscale.com/blog/introducing-planetscale-portals-read-only-regions

 

  * Docs
  * CLI
  * Enterprise
  * Pricing
  * Blog

Sign inGet started
BlogProduct
Follow us

  *  
  *  
  *  
  *  
  *  
  *  
  *  

We ship a lot, don't miss a thing.
[                    ]Subscribe
Introducing PlanetScale Portals: Read-only regions
Taylor Barnett
Taylor Barnett
5/24/2022
Product6 min read

Introducing PlanetScale Portals: Read-only regions

If you deploy your applications in regions around the globe and need
to keep database read latency low, you will want to physically have a
database nearby. With PlanetScale Portals, you can now create
read-only regions to support your globally distributed applications
and better serve your users worldwide.

Put your data where your users and applications are#

Portals allow you to read data from regions closest to where you
globally deploy your applications. Whether your application is
deployed near Northern Virginia, Frankfurt, Sao Paulo, or any of our
other PlanetScale regions, Portals can now provide lower read latency
for your applications!

Today, each database in PlanetScale reads and writes from a single
region. But with Portals, you can add as many distributed read-only
regions as you want.

Without PlanetScale, it can be a hassle to set up a globally deployed
database on your own. You might have to do capacity planning, deal
with complicated pricing structures, and worry about your replication
strategy or performance. Instead, with a couple of clicks, allow
PlanetScale to operate your additional read-only regions for you.

An example of the power of Portals#

To make this more concrete, let's look at the read latency between
different regions:

For an application deployed to Frankfurt, talking to a Northern
Virginia database can add nearly an extra ~90ms PER query. By adding
a read-only region in Frankfurt, we can reduce that to ~3ms per
query. (Data based on select * from books limit 10.)

Connecting to your new read-only regions#

You connect to your new read-only regions with a connection string,
just like connecting to any other PlanetScale database branch or
other MySQL databases. This connection string is specific to both
your read-only region and production branch.

Let's break down how this might look like in a Ruby on Rails
application deployed in both Sao Paolo and Frankfurt.

Code example

    Note: While the following example uses Ruby on Rails, depending
    on your application framework and how you deploy your
    application, there are often similar solutions for other
    technology stacks. For example, read the Fly.io and PlanetScale
    guide on using Fly's Global Application Platform alongside
    PlanetScale's read-only regions to deploy database regions close
    to your applications.

In a Rails application, you can set up a connection to your read-only
region.

First, modify your database.yml to include both a primary and
read-only region connection.

yaml
Copy

default: &default
  adapter: mysql2
  encoding: utf8mb4
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  username: root
  password:
  socket: /tmp/mysql.sock

development:
  primary:
    <<: *default
    database: multi_region_rails_development
  primary_replica:
    <<: *default
    database: multi_region_rails_development
    replica: true

test:
  primary:
    <<: *default
    database: multi_region_rails_test
  primary_replica:
    <<: *default
    database: multi_region_rails_test
    replica: true

This will allow you to send queries to your read-only region or take
advantage of Rails "automatic role switching" to route queries for
you.

ruby
Copy

ActiveRecord::Base.connected_to(role: :reading) do
  books = Book.where(author: "Taylor")
  # all code in this block will be connected to the read-only region
end

You can set up your production application to connect to your nearest
PlanetScale region for reads. This will result in your app having
low-latency reads.

In this example, we have our connection details stored in Rails
credentials.

ruby
Copy

<%
  # Our application has a region environment variable.
  # We check this variable and connect to the closest DB region.
  region = ENV["APP_REGION"]

  # When in Frankfurt, we use our Frankfurt region.
  # When in Sao Paolo, => Sao Paolo region.
  region_replica_mapping = {
      "fra" => Rails.application.credentials.planetscale_fra,
      "gra" => Rails.application.credentials.planetscale_gra
  }

  # If no specific region exists, we'll connect to the primary.
  db_replica_creds = region_replica_mapping[region] || Rails.application.credentials.planetscale
%>

production:
  primary:
    <<: *default
    username: <%= Rails.application.credentials.planetscale&.fetch(:username) %>
    password: <%= Rails.application.credentials.planetscale&.fetch(:password) %>
    database: <%= Rails.application.credentials.planetscale&.fetch(:database) %>
    host: <%= Rails.application.credentials.planetscale&.fetch(:host) %>
    ssl_mode: verify_identity
  primary_replica:
    <<: *default
    username: <%= db_replica_creds.fetch(:username) %>
    password: <%= db_replica_creds.fetch(:password) %>
    database: <%= db_replica_creds.fetch(:database) %>
    host: <%= db_replica_creds.fetch(:host) %>
    ssl_mode: verify_identity
    replica: true

Once this is in place, we can now have our globally deployed app read
data from our globally deployed database. This will result in much
faster GET requests for anyone in that region. Any writes will still
go to the primary.

Automatic role switching and reading your own writes

We can take this one step further by having all our read queries hit
the read-only region without specifying it in our code. We can also
tell Rails to read from our primary if the user recently wrote to the
database. This protects our users from ever reading stale data due to
replication lag.

To do this, we need to set reading/writing roles for our models:

ruby
Copy

# app/models/application_record.rb
class ApplicationRecord < ActiveRecord::Base
  primary_abstract_class

  connects_to database: { writing: :primary, reading: :primary_replica }
end

Then we can enable automatic role switching by adding the following
to our production config.

ruby
Copy

# config/environments/production.rb
config.active_record.database_selector = { delay: 2.seconds }
config.active_record.database_resolver = ActiveRecord::Middleware::DatabaseSelector::Resolver
config.active_record.database_resolver_context = ActiveRecord::Middleware::DatabaseSelector::Resolver::Session

This tells Rails to send all reads to our read-only region and writes
to our primary. After each write, it will set a cookie that will send
all reads to the primary for 2 seconds, allowing users to read their
own writes.

(Also, thank you to PlanetScale software engineer, Mike Coutermarsh,
for help with the Ruby on Rails code in this section.)

Pricing#

Any database on a Scaler, Teams, or Enterprise plan can create
read-only database regions. The pricing for Portals is based on
storage costs and row reads.

Storage costs

Your storage costs will increase linearly with the number of
read-only regions you purchase. For example, if your production
branch is 10GB, each read-only region added will increase your total
storage cost by 10GB. Portals' storage costs are prorated by month.
If you added a read-only region to your 10GB branch on the 15th,
you'll get billed for 5GB of usage.

Adding new read-only regions will always be billed as standalone
storage and will not count toward your included storage.

Row reads

Queries issued to your read-only region will contribute to your total
billable row reads per month. To make it easier to track the cost,
your invoice details will show a new line for rows read from any
read-only region.

Try it out today#

PlanetScale Portals is available in beta today. You can create a new
read-only region in any PlanetScale database on a Scaler, Teams, or
Enterprise plan.

Sign up or log into your PlanetScale account and go to your
database's production branch page to add a region. Read more in the
Portals docs.

If you have feedback, tweet at us @planetscaledata or post in our
GitHub Discussion group.

Next post

[image]

Company

Why we wrote the PlanetScale "Future Database" principles

We believe databases are lagging behind DevOps innovation and we
wrote these principles to illustrate the path forward.

Your business deserves a predictable database.

Your business deserves a predictable database.

Never worry about another 3am wake-up call saying the site is down.
Give your engineers the power they deserve with a PlanetScale
database today.

Get startedContact sales
 

Company

  * About Us
  * Careers
  * Blog

Products

  * CLI
  * Rewind
  * Enterprise
  * Pricing
  * Changelog

Open Source

  * Vitess
  * Vitess Community
  * GitHub

Resources

  * Docs
  * Support
  * Status
  * Contact

Talk to us

  * Call +1 408 214 1997
  * Contact Sales

  *  
  *  
  *  
  *  
  *  
  *  
  *  

(c) 2022 PlanetScale Inc. All rights reserved.

PrivacyTerms