Using the Prisma Data Proxy with Vercel, Prisma, Next.js, and PostgreSQL

Using the Prisma Data Proxy with Vercel, Prisma, Next.js, and PostgreSQL


Using the Prisma Data Proxy with Vercel, Prisma, Next.js, and PostgreSQL

In this video, you will learn about how the Early Access version of the Prisma Data Proxy solves database connection management in serverless environments.

The Prisma Data Proxy is an external connection pooler that sits between your app and your database so you can reliably use relational databases in serverless environments.

In the video, Daniel deploys a Next.js app built with Prisma and PostgreSQL to Vercel and runs a load test to show the database connection limit exhausted. He then imports the project to the Prisma Data Platform and configures the Prisma Data Proxy to eliminate database connection exhaustion.

Source code: https://github.com/2color/next-prisma

Sign up for Early Access to the Prisma Data Proxy: https://pris.ly/prisma-data-proxy

Timestamps:
00:00 The connection pooling problem in serverless environments
01:40 A look at the demo built using Next.js and Prisma
05:16 Deploying the application to Vercel without using the Data Proxy
06:16 Load testing to demonstrate the connection pooling problem using K6
08:12 A look at the Prisma Data Platform and setting up the Data proxy
12:20 Updating the Next.js demo project to use the Data Proxy
17:29 Adding the Data Proxy connection string to the project on Vercel
18:56 Setting to the Vercel build command to run migrations in builds
21:23 Running the load test with the Data Proxy and comparing the results
24:06 Summary

------------------------
📚 Resources:
✅ Subscribe to Prisma:    / @prismadata  
✅ Get help from the Prisma Community: https://slack.prisma.io/
✅ Learn more about Prisma:
◭ Website: https://www.prisma.io
◭ Docs: https://www.prisma.io/docs
◭ Quickstart: https://pris.ly/qstart

------------------------
💬 Connect with Prisma:
Twitter: https://twitter.com/prisma
Instagram: https://www.instagram.com/prisma.io/
TikTok: https://www.tiktok.com/@prismadata
Facebook: https://www.facebook.com/prisma.io
LinkedIn: https://www.linkedin.com/company/pris

------------------------
Prisma sponsors human-reviewed, professional closed captions for ANY video valuable to our community (for example, about: Node.js, TypeScript \u0026 Type Safety, Prisma, databases, etc). Get your FREE captions here: https://pris.ly/closedcaptions


Content

0.13 -> [Music]
6.879 -> welcome in this video i'm going to
9.679 -> demonstrate how to use the prisma data
12.16 -> proxy and show how it can solve some of
14.32 -> the connection pooling problems that are
16.56 -> very common to serverless runtimes and
18.96 -> so just to recap the common challenge
21.76 -> with serverless environments is that a
23.92 -> single serverless function handles a
25.92 -> single
26.96 -> user request
28.96 -> and every time one of these serverless
31.279 -> functions starts it opens up a new
33.76 -> connection to the database now the
36.32 -> moment that you reach
38.32 -> a lot of requests coming into your
40.719 -> serverless functions what happens
42.96 -> typically is that your database
45.2 -> connection limit is exhausted
47.6 -> moreover
49.039 -> opening up a connection and closing it
51.12 -> for every user request to the database
54.32 -> is quite costly time wise and it adds
56.879 -> latency so beyond the uh connection
60.719 -> limit exhaustion which leads to failed
62.8 -> requests there's also the added overhead
65.199 -> which adds slowness
67.04 -> this is where connection pullers come in
69.6 -> some of you may be familiar with pg
71.439 -> bouncer
72.4 -> a postgres-specific connection puller
74.96 -> that helps solve this problem however
77.28 -> typically pg bouncer is an additional
80.4 -> infrastructure component that you need
82.08 -> to run
83.759 -> as part of the prisma data platform our
86.4 -> vision to democratize data access and
88.64 -> make it as easy as possible to
91.36 -> collaborate and to iterate on projects
94.72 -> using a database and prisma
97.119 -> we are now introducing the early access
99.36 -> version of the prisma data proxy
102.88 -> in this video we're going to deploy an
105.36 -> xjs application that uses prisma
108.88 -> to versal and initially we're going to
111.28 -> deploy that without the prisma data
113.84 -> proxy
115.119 -> we'll run a load test to see how it
117.36 -> performs and to see the kinds of errors
119.439 -> that you encounter typically without any
121.759 -> connection pulling
123.28 -> and then we will add the prisma data
125.119 -> proxy and see how it performs with that
128.319 -> so here on the left hand side you can
131.2 -> see what it looks like when we just have
134.48 -> the versal functions connecting directly
137.04 -> to the database and then once we
139.28 -> introduce the data proxy it will act as
142 -> an intermediate infrastructure component
144.239 -> that is of course managed by prisma
147.04 -> and handles this connection pulling for
148.959 -> you
149.92 -> one thing to note is that there is an
151.28 -> additional benefit to using the prisma
153.76 -> data proxy by using the prisma data
156.4 -> proxy you essentially eliminate the need
159.28 -> to also package the prisma engine
162.4 -> into your serverless function
164.56 -> this should result also in faster
167.92 -> loading times of these serverless
170.56 -> functions because it takes less time for
172.48 -> them to load because of their lower
174.959 -> smaller bundle size
176.879 -> let's start by looking at the app so
178.879 -> here on the left hand side we have this
180.959 -> blog and
182.48 -> this blog is built with next js it uses
185.44 -> prisma as we can see on the right hand
187.28 -> side we have the prisma for this project
189.2 -> so we have a single post model and a
191.76 -> comment model with a one-to-many
193.519 -> relation between posts and comments in
196.48 -> practice this is what it looks like if i
198.72 -> open up the page you can see here that i
200.72 -> have a single blog post and the
202.4 -> different comments
204.159 -> i can also leave comments and
206.959 -> you can also see we have api endpoints
209.36 -> to increment the views count and also
212.64 -> an api endpoint so that we can increment
215.599 -> the likes for each blog post
218.08 -> and if we look at the right hand side
220.08 -> here we have the prism schema
222.56 -> and let's take a look at some of the api
224.879 -> methods so this is the api route
228.159 -> to add a comment to a blog post as you
230.4 -> can see it creates it and it links it to
232.239 -> the post id that gets passed in
236.159 -> to the
237.84 -> request body
239.519 -> we also have
241.12 -> the post endpoint
243.36 -> this one supports two http methods one
246.319 -> to get a single uh sorry to get multiple
249.84 -> blog posts and one in order to create
252.72 -> one blog post with a bunch of comments
256 -> uh we also have
258.079 -> an endpoint which gets which deletes a
261.04 -> specific
262.16 -> blog post so this is the one that gets
264 -> called if i click delete post and as you
265.68 -> can see it's been removed
268.08 -> and we also have
269.6 -> the two end points to increment
273.28 -> likes and
274.639 -> views and here we're using these atomic
276.8 -> operations that prismacline supports so
279.759 -> that you can ensure that it's
280.88 -> incremented by one without actually
282.8 -> having to fetch the data before
285.44 -> i also have this seed endpoint which is
288.4 -> called when i called reset posts
291.12 -> which deletes all of the posts and
294.8 -> uh
296.32 -> seeds the database with four blog posts
298.88 -> so this makes it just easier for us to
301.36 -> sort of play around with this blog
303.6 -> you may also notice that there's a
305.28 -> create post here i showed you the
307.12 -> endpoint for that and that just creates
309.039 -> a new post i can click that and as you
311.12 -> can see another one is created
313.68 -> let's get started with deploying this
315.36 -> application on the right hand side you
317.199 -> can see i've pushed all of the changes
318.88 -> to github and on the left hand side i
320.8 -> have the import window of versa
323.6 -> you can already see that in the package
325.36 -> json i've defined this versal step that
327.199 -> will just run prisma generate and next
329.28 -> build
330.4 -> now going to go ahead and import this
332.16 -> project i'm not going to create a team
335.12 -> and i'm going to have to define a an
337.199 -> environment variable here for the
339.919 -> database so let me just
342.96 -> copy
343.919 -> that in
346.08 -> base url i'm going to paste that
349.68 -> and
350.72 -> now we can go ahead and deploy this
355.44 -> great we've successfully deployed the
357.12 -> application let's take a look at that
360.16 -> so we go to the dashboard and then open
362.56 -> up the app and as we can see we have it
365.199 -> we can also
366.479 -> open these up and we can
369.919 -> like them we can leave a comment
372.479 -> and
373.919 -> that is all working
376.08 -> we will now look at some of the
377.36 -> challenges that typically arise in such
379.44 -> situations where you're connecting
381.12 -> directly to the database from serverless
383.52 -> functions so quick reminder serverless
386.16 -> functions are ephemeral and short-lived
388.56 -> that means that their database
390 -> connections are numerous and brief
392.479 -> because of this using relational
394.16 -> database in serverless environments and
396.56 -> functions often leads to exhausting the
398.96 -> connection limit of the database and to
401.52 -> increased latencies on each request to
403.759 -> establish the database connection
406 -> so let's take a look at what a load test
408.88 -> to this api looks like and how the api
411.68 -> performs under load for this i have
414.319 -> prepared a load test and the code for
417.759 -> the load test is here on the left this
420 -> is using a load testing tool called k6
424.08 -> and here we define a user flow that
426.08 -> makes a bunch of requests to the api it
428.88 -> creates it gets the blog posts it
431.36 -> creates a blog post it adds a comment
434.639 -> it adds a like and view to each one of
437.199 -> these and it does this here you can see
439.039 -> in the configuration that i have
440.8 -> 40 virtual users so that means that 40
443.919 -> 40 users will go through this user flow
446.639 -> and the duration of this load test will
448.72 -> be 10 seconds
450.88 -> so let's run this load test and what i
453.44 -> expect to see some failed requests as we
455.68 -> exhaust the database connection limit
458.08 -> and you can see that already through the
459.919 -> errors
461.199 -> once this load test finished we'll get
462.96 -> the full results for how the test ran
468.879 -> and so now that it's finished we can see
471.199 -> that the status was 200 for only 81
473.919 -> percent of the get post requests and
476.4 -> similarly for the other endpoints and if
478.879 -> we look at the logs in versa we expect
481.36 -> to see these errors
483.199 -> so basically we get these errors that
485.44 -> show us that the connection limit of the
487.36 -> database has been exhausted
489.919 -> okay how can we fix this
492.4 -> this is where the prisma data proxy
494.8 -> comes in
496.24 -> to make use of the prisma data proxy we
498.479 -> first have to create the project in the
500.319 -> prisma data platform to do this i'm
502.72 -> already logged in so i'm going to go
504.24 -> ahead and import a project and i'm going
507.199 -> to call this the next
509.84 -> prisma
511.759 -> data proxy
514.8 -> i'm going to also tell it which
516.959 -> repository so
518.839 -> next prisma data proxy
521.919 -> and it already detected where the schema
523.919 -> is i'm going to create the project
527.04 -> now that the project has been created
528.8 -> i'm going to connect it to an existing
531.279 -> database and for that i'm going to
534.56 -> take the environment variable
537.519 -> i'm going to paste that in
545.6 -> now it's connecting to the database and
548.16 -> we are connected
550.48 -> now that we have the database connected
552.56 -> i want to show some of the functionality
554.399 -> that the prisma data platform offers so
556.88 -> the first thing we have is the data
559.04 -> browser and the data browser essentially
560.8 -> allows us to explore the data that we
562.8 -> have in the database
565.12 -> it's essentially based on prisma studio
567.68 -> with some added functionality so for
569.6 -> example we have here the four blog posts
571.519 -> we can see that
573.92 -> this one has three comments and we can
575.68 -> see what those comments are one of them
577.279 -> has
578.32 -> four comments
580 -> and
580.88 -> we can also use this in order to modify
583.6 -> some of the data so i could go ahead and
585.2 -> write
586.56 -> read this and i could save those changes
589.12 -> and essentially this allows us to update
591.36 -> our data in the database
593.68 -> and now it's reloading and we see the
595.92 -> update
597.04 -> we can also explore the different
599.12 -> comments that we have
600.959 -> by opening that up
602.959 -> okay that was the data browser we can
605.44 -> also invite other members
608.399 -> to collaborating to also be able to
610.64 -> access the prisma data platform and to
612.48 -> explore the data we have a bunch of
614.8 -> different roles so that you can control
617.12 -> what permission level you want to give
618.959 -> to your collaborators
621.04 -> the other thing we have is the query
622.959 -> console and the query console is a good
625.519 -> place if you just want to sort of get
627.2 -> started and play out and see what
629.279 -> prismaclient looks like so for example
631.68 -> here i created a query
634.56 -> that finds
636.16 -> all the posts and it also selects the
639.44 -> relation count so it'll actually give us
641.76 -> the number of comments that each one of
643.76 -> these blog posts has and then it will
646.16 -> combine that with a feature known as
647.76 -> order by relation in order to order the
650.079 -> blog post in descending order by the
652.079 -> number of
653.44 -> comments that they have and so if i run
655.36 -> this query i expect to see of course the
657.2 -> first one with four comments and then
658.72 -> the second one with three comments
660.88 -> same thing with the third one and then
662.64 -> finally the one that has two comments i
664.399 -> can also of course
665.839 -> change this to ascending order
669.44 -> and of course of course i can also write
672.32 -> additional queries like i can write away
675.959 -> prisma.post.find many
678.399 -> and then i can also order that by
682 -> the
683.519 -> title in descending
686.399 -> or let's do ascending order and as you
688.959 -> can see you still get in this query
690.32 -> console you get the same auto completion
692.48 -> that you get in vs code so that was the
696 -> query console but we want to look at the
697.92 -> data proxy
699.36 -> so let's take a look at that here when
701.519 -> we go to data proxy we can essentially
703.519 -> select one of the two
705.36 -> locations that are available these are
707.519 -> deployed onto aws and of course this is
710.16 -> i should mention that this is an early
711.839 -> access version so expect this to get
714.56 -> even more polished
716.88 -> so i'm going to pick frankfurt because
718.56 -> that is also the same region that i'm
720.72 -> using for my database
724.56 -> and
725.92 -> i will enable it
729.04 -> and now we got this new connection
730.72 -> string and uh
733.12 -> now that we have this new connection
734.56 -> string and the token we can read the
737.76 -> docs on how to get this
740.079 -> set up with vessel
743.6 -> so here i have the prisma data proxy
746.24 -> public docs for the early access program
750 -> and besides an introduction we go to the
753.279 -> steps about how to switch to the data
755.519 -> proxy
756.72 -> and the first step as we've already done
759.36 -> is generating this proxy this data proxy
762.16 -> connection string which we have already
764.16 -> done i've pasted that locally
767.44 -> so that i can use that to also update
769.44 -> the versal secret and then the second
771.6 -> step is that we have to install a
773.36 -> special version of prisma this is while
775.279 -> this is still in early access and so i'm
777.76 -> going to go ahead to the package.json of
779.76 -> the project and update the prisma
782.72 -> dependencies
784.639 -> so here i have it um and i'm going to
787.44 -> just change that to use the special
789.92 -> version
790.959 -> and then go to install that
796.16 -> and we have that so that's been
798.959 -> installed successfully
801.36 -> now we can go into our schema and then
803.519 -> follow the next steps of the guide
806.48 -> and
807.44 -> the main thing that we need to do here
808.959 -> is we need to tell the
811.6 -> generator block to use the data proxy
814.24 -> engine type and so i'm going to copy
815.76 -> this line here and i'm going to paste it
818.56 -> in i'm going to format this so that it
820.88 -> looks nice
822.48 -> and we are pretty much ready um you can
825.92 -> go npx
827.36 -> prisma generate now
831.12 -> and
833.76 -> locally i can already connect through
836 -> the data proxy to the production
838 -> database so we will start with that
841.6 -> and i will go ahead and make sure that
844.399 -> my n file is updated
847.279 -> and so here i have the n file and i'm
849.839 -> just going to disable the line that
851.839 -> connects directly to the database and
853.6 -> use the data proxy url and you can
856.72 -> detect that because it starts with this
858.72 -> prisma that's how you know that you're
860.48 -> connecting through the data proxy
862.959 -> url so now that that's working i can go
865.76 -> ahead and already start the development
868.839 -> server and
870.88 -> npm run
872.72 -> dev
876.079 -> and that will essentially run the uh
878.56 -> development server for next js
881.519 -> and if i open this up
885.519 -> we should see that it's connecting
887.199 -> through this
889.04 -> if i go and i create a post
891.76 -> that is making an api request and we can
895.199 -> open this up already
898.32 -> and so now that we've opened this up i
900.32 -> can also add comment from
904.079 -> demo
905.199 -> and we can now go back to uh we can also
908.48 -> like the page and now we can go to the
910.639 -> prisma data platform
912.56 -> into the
914.079 -> data browser in order to see if the data
916.24 -> has been updated so i'm going to go here
918.24 -> to the data browser
920.16 -> and in the data browser i expect to have
922 -> those four posts that were suited plus
924.399 -> the additional one that we just
926.56 -> created
929.279 -> and let's go look at the posts
931.44 -> and
933.04 -> it's fetching the rows from the database
936.24 -> table
938.959 -> and here we have it it has a single view
941.519 -> and a single like and it also has four
943.759 -> comments and if we open that up we
945.6 -> should see that comment that i just
947.36 -> created and there we go there we have it
949.759 -> we have this add comment from demo so
951.92 -> that's all working locally
954.88 -> in the next step what we're going to do
956.72 -> is we're going to actually configure
958.56 -> versal
959.839 -> to connect
961.279 -> through the data proxy
963.68 -> to the database and just a quick
965.519 -> reminder we had this sort of diagram
967.36 -> here visualizing this so essentially
969.12 -> right now we have the versal functions
971.44 -> they're configured to connect directly
973.44 -> to the
974.72 -> postgres database on digitalocean
977.279 -> and we are going to change that we're
978.88 -> going to commit the changes because we
980.8 -> need to use the special version of
982.24 -> prisma
984.16 -> in the package.json that we updated and
986.399 -> we're also going to update the secret
989.759 -> so that the functions connect to the
991.839 -> data proxy so let's take a look at how
994.079 -> that works
996.16 -> before we update the secrets on versal
998.48 -> i'd like to commit the changes to the
1001.04 -> prisma ski mode to the package.json
1003.36 -> quick reminder that in the package.json
1005.68 -> we updated the dependency to use the
1007.519 -> special version for the early access
1009.6 -> program to connect to the data proxy and
1011.92 -> the second change was in the prisma
1013.92 -> schema where we added the engine type
1016.399 -> data proxy and so we will commit this
1019.6 -> now but we will not push this just yet
1022.88 -> because pushing this will trigger
1024.4 -> another build and we want the build to
1026.079 -> start only once we've also updated the
1028.959 -> environment variables so i'm going to
1031.199 -> commit the changes here
1033.36 -> and update to use
1036.64 -> data proxy
1039.439 -> and i will save that and now that we've
1041.28 -> committed this we can go to versal and
1043.839 -> update the
1045.36 -> environment variables
1048.799 -> i am now here in the versal project
1051.76 -> settings i'm going to go to the settings
1053.76 -> and to the environment variables
1056.559 -> and as you can see we also have this
1058.799 -> database url here and if i view it you
1062 -> can see that it starts with postgres
1064.16 -> that means that it is the connection
1066.559 -> string directly to the database and
1068.799 -> we're going to first rename this we're
1070.559 -> going to also need this in order to run
1072.799 -> migrations so quick pointer here is that
1076 -> when you are
1077.679 -> using the prisma data proxy you cannot
1080.4 -> run migrations through the prisma data
1083.36 -> proxy and so what we're going to do is
1085.039 -> we're going to create two database
1087.52 -> connection strings one is going to be
1089.36 -> used in order to run migrations and we
1091.28 -> will call that the migrate database url
1094.16 -> and then we'll just have the normal
1095.28 -> database url which is used in order to
1097.679 -> connect through prismaclient to the data
1099.919 -> proxy so first step i'm going to edit
1102.48 -> this
1103.28 -> and i'm going to rename this to
1105.919 -> my great database url
1108.799 -> i'm going to save this
1111.6 -> and then we will go here and we will
1113.84 -> call this database url
1116.88 -> and i'm going to paste the
1121.28 -> connection string that i got from the
1123.28 -> prisma data proxy and i will add this
1128.16 -> and this is pretty much uh
1130.96 -> all we need to do we are now going to go
1133.28 -> back to the code base
1136.64 -> and we are going to
1139.28 -> change in the package json here we're
1142.16 -> going to change this migrate deploy
1144.24 -> command and
1146.96 -> we're going to change this to be as
1149.679 -> follows so
1151.28 -> it's going to look like this
1153.52 -> and basically what this will do is it'll
1156.48 -> reassign the database url to use this
1158.799 -> one that connects directly to the
1160.48 -> database and then run deploy
1162.88 -> to make sure that migrations are applied
1165.12 -> during the versal build step we're going
1166.88 -> to add the
1168.72 -> npm run migrate deploy to the versal
1172 -> build step
1174.32 -> now that we've done that i'm going to
1175.76 -> commit this change to
1179.679 -> and
1187.2 -> directly
1190.64 -> and now i'm going to push this
1192.48 -> now that it's pushed we can open up
1194.24 -> versus again and see what is the current
1196.64 -> state
1197.919 -> if we look at the deployments
1199.76 -> we have this one which
1202.88 -> was triggered by the push
1208.32 -> and
1210.64 -> we can take a look at how that's going
1212.72 -> we should also be able to see
1215.52 -> it attempting to
1217.28 -> run the migrations because we've updated
1219.44 -> this reversal build step in the package
1222.32 -> json
1230.64 -> and indeed here we have it
1233.2 -> this is where it's running these
1235.12 -> migrations and you can see that it's
1236.64 -> running them against uh digital ocean
1239.44 -> but there are obviously no pending
1241.039 -> migrations to apply that's because we've
1242.64 -> already
1243.679 -> uh random migrations
1247.28 -> and so it looks like
1249.28 -> the build is almost complete
1256.24 -> and once the build completes we're going
1257.76 -> to open up
1258.96 -> the deployed app and take a look at how
1261.919 -> that works and then we're going to run a
1264 -> load test to see
1265.679 -> how this application fares
1267.919 -> with a heavy load
1270.96 -> and whether it exhausts connections as
1272.64 -> we expect it to the prisma data proxy
1275.28 -> will handle all of the connection
1276.799 -> pooling and we shouldn't see the same
1278.96 -> errors that we saw as we did in the
1281.2 -> first load test
1283.2 -> we are now going to run a load test
1285.76 -> against the deployed api using the
1287.84 -> prisma data proxy from my local machine
1290.4 -> we're going to use the exact same load
1292.159 -> test that we used before that gets a
1294.559 -> post creates a post adds a comment
1297.679 -> increments the views and increments the
1300.08 -> likes for that created post so let's go
1304 -> ahead and run that and this test will
1305.84 -> run with 40 virtual users
1308.64 -> that means that 40 users will be running
1311.28 -> through that
1312.24 -> load test concurrently and we expect to
1314.88 -> see that none of the requests
1316.84 -> fail here we have the results from the
1319.36 -> first load test that was connecting
1321.44 -> directly to the database from reversal
1323.44 -> functions and on the right hand side we
1325.84 -> have the version that we just ran of the
1328.24 -> load test which uses the prisma data
1330.4 -> proxy in between and indeed we can see
1333.039 -> that here that
1334.559 -> uh
1336.12 -> 1115 requests were sent in total
1340 -> that means about 96 requests per second
1342.799 -> which is quite a high load
1344.96 -> and if we see here at the
1347.28 -> number of requests that have failed we
1349.039 -> can see that that's zero percent so
1351.84 -> here we have it we've first of all we've
1354.159 -> eliminated the connection polling
1356.159 -> problem we're no longer exhausting the
1358.159 -> connection limit of the database and
1360.4 -> let's take a quick look at some of the
1362.159 -> performance for all of these endpoints
1363.84 -> and we have that
1365.2 -> here in these first lines that we have
1368 -> highlighted here
1369.76 -> and what we can see is that some of the
1372.88 -> endpoints average at about 150
1375.28 -> milliseconds
1376.96 -> but the main thing to note here is that
1379.36 -> we no longer have the database
1382.88 -> connection exhaustion problem
1385.919 -> another reason for this deviation that
1387.919 -> we're seeing
1389.039 -> for some of the requests
1391.6 -> could be the cold start problem and the
1393.919 -> cold start problem could be stated as
1396.88 -> the situation in which you're calling a
1399.919 -> serverless
1401.36 -> function for the first time and it is
1403.52 -> not loaded in cache which means that aws
1407.2 -> lambda in this case has to sort of load
1409.28 -> that function for it to run and after
1412 -> it's loaded aws lambda keeps it around
1414.799 -> in case another request comes in and
1417.28 -> when another request comes in it reuses
1419.6 -> that existing
1421.36 -> hot function or container
1424.48 -> these are all terms referring to the
1426 -> same thing and so this might be a good
1427.919 -> explanation for why we're seeing such a
1429.679 -> deviation from the minimum amount of
1431.76 -> time
1432.64 -> to the average which is a bit higher
1435.84 -> but the good news is that in the minimum
1438.08 -> case when there is no cold start
1441.039 -> we get a response pretty quickly within
1443.44 -> under 100 milliseconds
1447.679 -> let's summarize what we did today
1450 -> initially we started off with an xjs
1452.32 -> project that used prisma prisma was used
1455.44 -> both in
1456.799 -> the server side rendering and the static
1459.679 -> site generation using the get static
1462 -> props
1463.12 -> of next js
1464.72 -> we can also take a look at the api
1467.919 -> endpoints for example
1469.84 -> the get posts endpoint
1473.039 -> and the
1474.08 -> single delete post endpoint
1476.64 -> so all of these endpoints were using
1478.4 -> prisma in order to interact with the
1480 -> database
1481.279 -> we
1482.08 -> imported the project into versal where
1485.279 -> it was deployed
1486.88 -> and we connected it with a database that
1489.679 -> i created in the same region the
1491.36 -> frankfurt region
1494.559 -> and after we connected to the database
1496.799 -> we looked at it we ran the load test and
1498.64 -> we saw how many of the requests failed
1500.88 -> because of the database connection
1503.2 -> exhaustion
1505.36 -> that's when we introduced the prisma
1507.36 -> data platform and a quick refresher
1510 -> essentially we were going directly from
1512.48 -> the versal functions to the database
1515.6 -> and that resulted in that connection
1517.279 -> connection exhaustion and then once we
1519.52 -> introduced the prisma data proxy that
1521.039 -> was able to hold the connection pool
1523.44 -> to the database in digitalocean which
1526 -> then eliminated a lot of the errors that
1527.76 -> we saw in the load test
1530.559 -> and so here i still have the
1533.6 -> app that is deployed using the prisma
1535.52 -> data proxy and i can go ahead and create
1538.24 -> a blog post i can open that blog post up
1542.159 -> and i can go ahead and increment the
1545.76 -> likes i can also
1547.84 -> add a new comment and if i open up the
1550.4 -> developer tools here
1552.4 -> we will see this request and
1554.64 -> this request was served within 87
1556.72 -> milliseconds let's take a look at how
1558.32 -> long it takes to
1559.919 -> uh make a call to increment the views
1563.12 -> and there we have it within 80
1564.64 -> milliseconds that was a pretty good
1567.76 -> latency
1568.96 -> i should note at this point that
1571.76 -> while the prisma data proxy solves a lot
1574.559 -> of the problems associated with
1576 -> serverless
1577.44 -> we may still see some problem known as
1579.84 -> the cold start problem and the cold
1582 -> start problem could be stated as the
1583.84 -> situation in which a serverless function
1586.96 -> is instantiated for the first time and
1589.039 -> it is not cached and so
1591.12 -> the runtime in this case
1592.799 -> aws lambda has to actually load up the
1595.84 -> function in order to serve the user
1597.919 -> request
1598.96 -> typically what happens is that aws
1600.96 -> lumber keeps that
1603.12 -> serverless function around in case
1605.36 -> another request comes in and when the
1607.84 -> following request comes in it's usually
1610.159 -> served much quicker and so i expect that
1613.2 -> these low latencies that we're seeing
1614.72 -> now are thanks to a hot start of a
1617.76 -> serverless function probably because
1619.44 -> i've already been interacting with this
1621.039 -> app
1621.76 -> and
1622.72 -> because aws keeps them around for a
1624.559 -> couple of minutes
1627.039 -> so in that note we'll wrap up
1629.279 -> i highly recommend if you haven't
1630.64 -> already sign up for the early access
1633.679 -> program
1635.12 -> in order to try out the prisma data
1636.88 -> proxy and if you have any questions
1639.039 -> please be sure to leave them in the
1640.32 -> comments
1642.63 -> [Music]

Source: https://www.youtube.com/watch?v=iyGZ8JFPgoY