When it comes to page speed on the web, every second – every millisecond even –
counts. The faster that pages are served, the happier your users are and the
more likely they are to be kept engaged. Server-side rendering that relies on
dynamic database queries can only be as fast as the slowest query allows.
Caching is often introduced to speed up that database bottleneck, but caching is
a complex highly technical software engineering problem.
PolyScale is a no-code, plug and play database caching service that gives all
the benefits of a database cache without any changes to your existing codebase
or database architecture.
If you are not familiar with this stack, Next.JS allows developers to build
React applications, providing many features out of the box such as static and
server rendering, code-splitting and TypeScript support. Prisma is a Node.js and
TypeScript ORM which makes database access and management easy by utilizing a
schema to declaratively define your application’s models and their relations and
auto-generating a client from said schema.
The application reflects the architecture and configuration common to web applications the world over. A front page presents an overview of the catalog (in this case of real estate properties) and each property has its own details page.
for each property is rendered on the application server as it is requested.
Rendering the page requires five queries to the database. The first query
fetches the property, the second computes the median price for similar
properties in the same region, the third fetches the last sale of the property,
the fourth the last sale of similar properties in the region and the last simply
fetches a list of similar properties.
These queries reflect the range of demand put on the database server by a
typical web application. In total, the queries required to render the details
page constitute substantial load on the database. It’s an ideal candidate for
data caching and an ideal test to demonstrate the efficacy of PolyScale.
Solving cross-region latency
The application server and the database are hosted in the US, specifically on
Heroku’s us-east-1 region. For users in the US, a single details page load
(HTTP GET) completes in around 400ms. This constitutes the baseline level of
Let’s now assume our real-estate application wishes to expand to support
European users. With our current architecture, this is where we start to see
geographical latency challenges emerge. Making the same request from the EU the
average execution time more than doubles to 830ms. That’s a 105%
Scale the application tier
A logical architecture change to attempt to mitigate this is to add a dedicated
application instance in the Heroku EU region (eu-west-1 – Ireland). This
lowers the page load time (HTTP GET request) to 682ms as the page load
computation is decoupled and the static asset serving is done closer to the EU
Below we plot the execution times for each of these three scenarios. These
values are averages of the execution times of 300 consecutive requests.
The reason users in the EU experience such drastically different page load times
is because the database server is still located in the US. Duplicating the
application server in the EU does reduce the http latency for the EU users, but
because the queries to the database still must travel around the world, EU users
are served much slower than US customers (279ms slower).
A common architectural solution to this problem is to replicate the database
server as well as the application server or, develop application level caching
with databases like Redis. However, that brings with it significant cost and
Scale the data tier
Alternatively, PolyScale can be used to cache the data locally to the region.
PolyScale is a no-code, plug and play database cache as a service that can be
implemented in minutes by simply updating the PostgreSQL connection string used
by Prisma. PolyScale will then cache the data at the nearest Point of Presence
(PoP) dramatically reducing the latency between EU and US.
Connecting the EU application server to the database through PolyScale’s EU PoP
reduces the page load time to under 100ms. With the introduction of
PolyScale, EU customers are served 4x faster than the original baseline US
customers. All this benefit is had without any changes to the codebase or
With the introduction of PolyScale, EU customers are served 4x faster than the original baseline US customers.
Solving database concurrency
PolyScale’s caching has two benefits, reducing geographic latency and increasing
database read performance and hence concurrency. Here we demonstrate the latter
by introducing our application to an increasing number of concurrent users. We
alter the configuration used above by utilizing a PolyScale PoP for connections
within the US region.
Without PolyScale, as the number of concurrent users increases execution time
rises rapidly. This is because the database server becomes overburdened. With
PolyScale, the execution times rise much more gradually. For the same level of
execution time, the PolyScale based architecture supports 5x as many
The same dramatic effects are seen with our EU based application server
connected to the PolyScale EU PoP.
For the same level of execution time, the PolyScale based architecture supports 5x as many concurrent users
PolyScale accelerates data-driven apps in two ways: it lowers geographic latency
by using its global network of Points of Presence (PoP’s). Secondly, it
accelerates query performance and concurrency for database reads.
PolyScale can be implemented in minutes without writing code and the platform AI
will continuously monitor all database traffic providing insight and
recommendations on what to cache and for how long.
The source code for the demo application can be found here.
Ready to try PolyScale.ai? Signup for an always free account here (no credit card required) or try out the live interactive demo playground.