By Paul Scanlon

How to use Postgres at the Edge

Project Overview

This is my first project since joining Neon, itā€™s actually a little something I was playing around with while kicking the tires during the interview process.

What does Ping Thing do?

Ping Thing visualizes the journey your request makes from the Edge Function to the Database. Itā€™s a simple concept but itā€™s something I know is often misunderstood.

Ping Thing

Problem

I set out to show how to use Neonā€™s serverless driver with Vercel Edge Functions. Not a big deal right? Well, it is kind of a big deal. Allow me to explain. Neon is Postgres (in the cloud) and to connect to a Postgres database you have to make a server-side request over TCP/IP. Edge Functions, which run in V8 Isolates donā€™t operate over TCP/IP, they only speak HTTP. So in short, you canā€™t (for the most part) use a Postgres database from an Edge Function.

Solution

But you can use Neonā€™s serverless driver with Edge Functions, and hereā€™s why. Neonā€™s has separated compute and storage. The ā€œcomputeā€ part of Postgres is now no longer a TCP/IP connection. In front of every Neon database is a Neon proxy. When you make a server-side request to a Neon database youā€™re actually making a request to the Neon proxy, which in turn connects to the database over TCP/IP.

This change in architecture means you can make HTTP requests to the proxy, but youā€™d never know from looking at the connection string.. look familiar? It should, itā€™s a standard Postgres connection string,

postgres://paul:abc@firefly-123.us-east-1.aws.neon.tech/neondb

Insight

Iā€™ve experimented a lot with regions and where to deploy serverless functions (Lambda functions) and where to deploy databases and have spoken with a number of people about the subject. For the most part, based on the conversations Iā€™ve had, very few really understand it.

Perhaps thatā€™s ok. Many of the new ā€œpaid servicesā€ we all know and use aim to remove the need to think about infrastructure, but Iā€™m of the opinion that you will need to think about some of it, at some point.

The TLDR here is: Edge Functions (Lambda@Edge) run closer to the user, which is great, they also donā€™t come with the dreaded cold start issues that you might have experienced with ā€œordinaryā€ Lambda Functions. But are they the silver bullet weā€™ve been lead to believe they are. IMO meh, maybe. They are great for things that can be accomplished at the Edge, returning Hello World for instance, but as soon as you need to connect to another service, you have to ask yourself, where is that service?

In the case of Ping Thing Iā€™ve deployed the database to AWS us-east-1, which is located in North Virginia USA.

I had one person ask why didnā€™t I deploy it somewhere in Europe so it was closer to his location. To which I replied, ā€œI could have, but then itā€™s further away from folks in the USā€. So really then, what does it matter if the Edge Function runs closer to the user when the thing the Ege Function is connecting to is thousands of miles away?

The Idea

The idea was to simply show that Neon can be used at the Edge (Ordinary Postgres canā€™t) and the Globe is there to show you the journey you request makes.

If youā€™re on the US side of the Atlantic in North or Central America youā€™ll likely see a shorter journey.

Mexico - North Virginia

If youā€™re anywhere else in the world, youā€™ll likely see a longer journey.

Albania - North Virginia

That said, the response times are still super snappy. Neon have worked super hard on this part of the architecture and from the testing Iā€™ve been doing, Iā€™m happy with the latencies Iā€™ve been experiencing.

Blog

Iā€™ve written more about this project on the Neon blog if youā€™d like to give that a read.