Recap: What is Prisma Postgres?

In case you haven’t heard: Prisma Postgres is the first database built on unikernels. Here’s a quick 100-second summary if you missed it:

Built on next-generation infrastructure

Prisma Postgres is not just another AWS wrapper! Its architecture has been carefully designed from first principles and builds on next-generation infrastructure like unikernels, Unikraft Cloud and Cloudflare Workers.

The combination of these technologies provides unique benefits and a powerful feature set.

No cold starts, global caching, real-time events & more

Here’s what developers get when using Prisma Postgres as their serverless database:

• Zero cold starts: Instant access to your database without delays.
• Generous free tier: 100k operations, 1GiB storage per month & 10 databases.
• Global caching layer: Query responses are easily cached at the edge.
• Built-in connection pool: Scale your app without worrying about TCP connections.
• Real-time events: Event delivery with at least once and same order guarantees.
• Performance tips: AI-powered recommendations for speeding up your queries.
• Simple pay-as-you-go pricing: Predictable costs based on operations & storage.

Try Prisma Postgres

Life of a Prisma Postgres query

With our short recap out of the way, let’s dive into the tech stack Prisma Postgres uses to enable these benefits. Spoiler: Here’s the full overview of all components involved in the lifecycle of a Prisma Postgres query:

In the next sections, we’ll take a closer look at each stage and explain what’s going on under the covers.

Stage 1: It all starts with Prisma ORM

Prisma ORM is where the journey of a Prisma Postgres query naturally starts.

No query engine needed on the application server with Prisma Postgres

If you’ve used Prisma ORM in the past, you may be aware that it uses a Query Engine that’s implemented in Rust and which runs as a binary on your application server.

Note that while we’re still talking about the Query Engine being written in Rust in this context, it is currently being rewritten in TypeScript. Learn more here.

The core responsibilities of the Query Engine are:

• Generating an efficient SQL query based on the high-level ORM query (written in JS/TS)
• Managing the database connection pool

The neat thing about using Prisma ORM with Prisma Postgres though is that you don’t need the Query Engine running on your application server. Instead, you’ll use a super lightweight version of Prisma ORM without the Query Engine. The heavy-lifting of generating SQL queries and managing TCP connections is pushed down further in the stack into the connection pool that sits on top of Prisma Postgres.

This approach of hosting the connection pool on the Prisma Postgres infrastructure has major benefits: Freeing application developers from managing the connection pool lets them focus on their data needs and queries. It is also especially useful in short-lived environments, like serverless and edge functions, where re-creating the connection pool again and again causes a major performance overhead.

Defining a Prisma ORM query with a cache strategy

Let’s use the following Prisma ORM query for the purpose of this article:

This query fetches all published posts from the database and additionally specifies two parameters that will be relevant for the Prisma Postgres cache:

• Time-To-Live (ttl): Determines how long cached data is considered fresh. When you set a TTL value, Prisma Postgres will serve the cached data for that duration without querying the database.
• Stale-While-Revalidate (swr): Allows Prisma Postgres to serve stale cached data while fetching fresh data in the background. When you set an SWR value, Prisma Postgres will continue to serve the cached data for that duration, even if it’s past the TTL, while simultaneously updating the cache with new data from the database.

In this example, the data will be considered fresh for 30 seconds (TTL). After that, for the next 60 seconds (SWR), Prisma Postgres’s cache will serve the stale data while fetching fresh data in the background.

Prisma Postgres serves cached data from an edge location close to your application. If you deploy your app to multiple locations, this global cache can dramatically improve the performance of your app!

Executing the query via HTTP

So, when the query above is executed in an application, what happens next? Because the Query Engine has been pushed down the stack, all that happens at this stage is an HTTP request to the first auth and routing layers of Prisma Postgres’ infrastructure. This HTTP request carries a lightweight, JSON-based representation of the query. Here is what it looks like:

Note that the selection argument specifies the fields that should be fetched from the database. Since we didn’t us