“Serverless” Databases

Boss and Scott

CSD.

Welcome to Syntax.

On this Monday, hasty treat. We're gonna be talking about serverless Databases.

You know, when you get into serverless anything, one of the question that always comes up is, what about databases? So we're gonna be answering that question for you and quite a bit more today. This episode is sponsored by 2 amazing companies today, Prismic and LogRocket.

LogRocket is an incredible service to really get visibility in how people are using your thing.

As in what LogRocket gives you is a set of replay tools that allow you to understand conversion, allow you to understand what users are doing user behavior, it. But also understand where there are issues.

In fact, you can get access to a scrubbable video replay to solve bugs that gives you then access to the network tab error log and all that and more.

You can also increase it. Your conversion and optimize your adoption by understanding exactly why users are leaving at various points in your funnel.

Now there's also user experience analytics, front end performance monitoring, and so much more. So head on over to logrocket.comforward/syntax, And you'll get 14 days for free.

We are also sponsored by Prismic.

They are a headless CMS that provides Like, obviously, they have the API and all that really good stuff, but they have fantastic tooling, around building your website. They encourage you to Think of your website as a slice machine, which is essentially every little every little component that you have, make an associated input in Prismic with that. And then your marketing people, your lawyers, the people that are running the website, you yourself can go ahead and edit That content, you can click together those slices, and then you you jump into your Next or Nuxt or or or React or whatever it is that you're working with, and you create components that are associated with each of those slices, and then your user can just kinda put them together, and it's a website builder from there. It's awesome. Check it on out at prismic.ioforward/syntax.

They have tons of really good examples.

Just by doing a quick scan of the website, I think you'll understand how it all works. Thank you, Prismic, for sponsoring. Sick.

So once I, myself, am admittedly Underskilled in both serverless and whatever this idea of serverless database stuff goes. So I am going to be asking you some dumb questions as you talk through some of this stuff, and, hopefully, that can provide some insight for the listener who might also not know anything about this. So Do you wanna maybe give a little bit of an overview as terms of, like, why is a database Have to be different for serverless solutions? Or what's what why does it have to be different? Yeah. So I I think, like, real quick,

the benefit of serverless is that, the you you let's say you have some code that will, it.

Generate a PDF or send a push notification or whatever. That's the idea with serverless is that you just create these little functions like you would in regular JavaScript.

However, if the demand for that, function is increased at any time, then it will scale up very quickly. And if the demand goes away, then you're not you're not running that code at all. It. So that's that's kinda what serverless is at a high level view. We've got lots more podcasts on that. And sorta along with serverless, you have this idea of edge functions, which Essentially is the same thing, except where the function is running is very important, meaning that your edge function Might be distributed onto 40 different servers around the world. And Scott hits the 1 in Colorado, I hit the 1 here in Toronto, and somebody else will hit 1 in Europe depending on on where they're going. And so I I've been feeling pretty comfortable with serverless over the last couple years, but The database aspect of it has always been a little bit, like, shaky to me. So I thought, okay. Every time I come up with a new project that I need to do, I I always like to learn a new piece of tech. So my problem was I have this website, Wes Boss, with two s's, .com, And I got an email the other day. It says, hey. Your website's down. And somebody screenshotted it, and it was west b o s s s.com, and I realized I had not been redirecting that. So I looked at the cloud flare stats and, like, something like 400 people a week were going to the wrong domain.

Wow.

I thought, okay. I need to I was just realigning in. Yeah. I need to do something about it's probably a lot of you listening to the podcast because I don't I don't I say go to westboss.comforward/courses, and A lot of you say, alright. Well, that's how you spell boss. Right? My boss is one s. So I thought I'll make a silly little website as I do, That will just redirect the user. But for this one, I want to, I wanna host it with Dino, And I want to have some sort of database, and there's no database really needed for this thing. So I made a hit. Yeah. But just essentially every single time someone hits the website, I do 2 things. I query from or I update the number of hits in the database, and then I query the number of hits back from the database.

Just to just show, like, some load on there. So I made a simple little website with Deno that is server rendered, and then I, used a database called PlanetScale.

It's a MySQL hosting. We'll talk about all the solutions in just a second.

And then I just grabbed a, I just grabbed a node MySQL framework. Actually, it's from Planet Yeah. It's a node package, but I ran it in Deno no problem. I deployed it to Deno Deploy, and then ran the database on PlanetScale. And I asked Ask on Twitter, like, what should I what should I be using? And a lot of people are saying, yeah, check out PlanetScale.

So it was it was really yeah. It's it's kind of a cool website. So when you say you use this node package to work with PlanetScale,

is that kind of like a friendlier way? Because I know we had talked offline a little bit ago About you writing SQL queries and stuff, do you still have to write SQL queries with this package?

Yes.

But that is just because I decided to go straight into the database. That is not a limitation of the package because it's it's a MySQL database. So you can literally you could use You could use Prisma if you wanted. Yeah.

SQLite, is there any of that stuff? Yeah. SQLite. You could literally use anything that that Runs SQL queries, but I didn't want to get into that. I wanted to just I was just selecting a value from the database. So I was just writing raw SQL queries, which I have not done in Probably 12 years.

Amazing. I was just like sitting there. I was like, I don't know what to do. Like, I know the select star from whatever, but

I didn't know much past that, so I had to look it up. I hear you. I would have to I would have to get into some heavy docs if I was going to be doing that by hand right now. Yeah.

So I deployed this thing and I tweeted it out. And first of all, the Dino deploy unreal. It's so Obviously, it's super, super simple. There's no build step or anything like that. But from git commit push to it being live was 1 or 2 seconds, if that.

And it shows you as I tweeted it out, it shows you where it is spinning up around the world because, Deno is It's edge, meaning that it will run on all their servers around the world, and it's really cool. It shows you popping up in Africa and in Europe and in, Toronto and in all all around the world, and it's it's actually kind of cool. So that code that is running westb0 s s.com is running on probably 40 different machines around the world, and all of those machines need to connect to database. So that's kind of our next step is that, like, why can't you just use a regular why can't you just use a regular database with serverless functions? It. So with most traditional databases, you connect to them.

Your your app starts. Right? And when your app starts, you connect to your database, and then you have this reference to your database throughout the life of your application, and you could query and pull data and save data. Right. Like you're used to that, right? Scott, I mean, you it doesn't matter that it's MongoDB. All databases kind of work that you do one connection. You

You export whatever database instances or you access that database instance. And then anytime you Run your queries. It's using that already preexisting connection.

Right? Exactly. Yeah. So the problem with serverless in this case, is that if you have 40, 50 different things running or if you have a spike In traffic, somebody very popular tweets out your your thing, and all of a sudden you have a 1000000 people on your website in one go.

You're not going to be able to connect to your database a 100 times without that that working. There's generally a limit to the amount of at times that you can connect to an actual database.

So the solution to that is this thing called connection pooling, which essentially is that you you create a connection, and then you you run a server somewhere that is Taking in requests and just basically send sending them over that single one connection that you have.

However, Then you've just introduced a single server.

Yeah. Right. A single point. Yeah. Yes.

That's the bottle that's kind of the bottleneck at at that point is that, okay, now you have a single server. So so the solution to that is, you either use a service that will be able to handle and scale up the connection pooling for you.

So in my case, I use PlanetScale and part of so PlanetScale is a MySQL database host.

They just host MySQL databases. But part of their secret sauce is that they will allow you they will do the connection pooling for you.

It. So as long as you you you connect to it in a specific way that you show that you're doing connection pooling, they will try to scale that up for you, rather than you having to run from some infrastructure there. So you you still are doing it, but they are sort of, like, handling that Sauce under the thing, which I think is a really neat way to approach it because I really like that it's still MySQL.

I'm not buying into some proprietary solution here, but they have secret sauce, which is, Like, I can run at my SQL commands, but they will handle all of the connection pooling for you.

So That's solution number 1, and that is typically how you will be approaching these, at least at least from my a Slim experience. There's probably people that are much larger experts than me learning in 1 week.

But that's The sort of the one solution.

The other solution is you use like purpose built databases that do not use the connect keep the connection open and whatnot. They use basically stateless, connections, meaning that you send a request the database the database handles the request and then sends a response back much like a HTTP

server. Yeah, exactly.

It. So, that is pretty popular as well, in this space. The other thing people are asking is, like like, if you have Edge functions, but But you have 1 database that's hosted in Colorado.

Don't isn't that sort of foregoing the whole benefit of Edge? Because the idea with Edge is that the code is running as close to AU as possible, right? And the answer to that is there are people trying to figure out how to replicate databases Across the globe? I think that's kind of tricky because, like, if I update mine in Toronto and then Scott queries My profile in Colorado that has to, like, replicate extremely quickly across

all of the instances. Right? Right. And at that point, does that negate Any of the latency that you're removing by being at the edge in the 1st place, if it's having to then do Some other connections and talking before that data is, you know Yeah. Considered to be official or or locked in there. I forget what the The term is that they typically use. Also, I I always thought this is what I always thought this is what PlanetScale's secret sauce was. I thought they were doing, like, an edge a database,

but it's just connection pulling. No. They do they do a lot more than that. They do scaling and and whatnot. And I I talked to a couple of people from I'll talk about because mine did go down.

I'll talk about that in just a second.

But I think they they do a lot more, and it seems like people really like them, especially it. In the PHP world, because MySQL, PHP, they're they're pretty good friends.

So the Yeah. Tell them. The other thing that we should know about edge databases is that These like, you run an edge function, the connection from your edge function to where your database is hosted is way faster than The connection from your cell phone to the actual server. So that's called backbone or backhaul, meaning that like these every ISP That is running. They are all connected on fat pipes, and they can talk to each other much more quickly than your cell phone That is half underground in the subway, Ken. So that is Yeah. At least as I understand it, not as big of a deal Okay. The initial request from your phone to the server, but there still will be some inherently the in that. Yeah. Yeah. Well, like if you I gotta go from Australia to to Virginia. There's certainly it it's gotta get on a train somewhere and go through the middle of the earth. You know, there's there's pipes.

So

at least they're fat pipes, though, you know, they're fat pipes. Exactly. Exactly.

So I put this thing out there and I said, like, I just tweeted out. I said, like, go for it. Give me as much traffic as you can because I really want to see, Like, will this really hold up? And like like, obviously, I'm nowhere near, like, actual companies that get millions of requests a day, but I had a couple people.

They must have some sort of servers, but people sent me 250,000 requests in less than an hour.

And Deno, no problem. Actually, I went over the free plan on Deno. And, like, I don't I didn't tell Deno folks I'm gonna do this or whatever. I just signed up and deployed it within like 10 minutes. And Dino handled it without, without a sweat.

But at a certain point, the database Didn't go down, but the database started throwing errors. And I said, oh, like, what's the problem here? And I talked to the folks from PlanetScale, like, Is this a is this a connection pooling limit? Like, did I hit too many pooling? And they said, no. It's not a connection pooling limit, but What you had done is synchronous requests. So I was incrementing a number every single time someone hits the thing. So what happens when a 100,000 people hit an endpoint or let's say 10,000 people hit an endpoint at the same time.

What do you return? Right. Because You have to increment it, send it back, increment it, send it back. So what was happening was because of the type of query I wrote, they had to queue up.

20,000, increments and then return those all. And at a certain point, I hit the limit of the free plan.

So apparently, that will go even higher on a paid plan. So I thought that was kind of cool. And I think you probably like, we had the show on serverless limitations.

You should probably think about that type of request if you are scaling up because essentially every single request depends on the request before it. Right. So they were sort of queuing up very, very long. And at a certain point, I hit the I hit the limit of it. So, but other than that, it was I only went down once or twice over the what's it at right now? 327,000 Request that somebody somebody out there has some freaking servers that was able to very quickly send a very a high amount of traffic.

Someone someone out there's got some servers and some fat pipes ready to send over some data. Yeah.

So So let's talk about actual solutions out there.

There are different solutions. You gotta think about relational databases, MySQL, Postgres, all of those, Versus nonrelational data databases, which is often called NoSQL, where they just save all of your data in columns.

Then past that, you gotta think about proprietary versus open standards. So there are Lots of proprietary services out there, Firebase, Cloudflare, where they say, alright, use our database. This is how you use it. This is our API.

And then there are also lots of open standards like, PlanetScale and what are what are the other ones here? Supabase, Neon.

Those are MySQL Postgres, which I very much like because you're just writing Standard stuff. I can run a MySQL database locally. No problem.

However, they are like a CS service as well that will allow you to scale up. And I always think about, like, what happens if I wanna move out of this type of thing? And for a lot of people, I say, it's fine. We'll We'll lock into the proprietary database because of all the benefits. We're gonna go all in on it. This is not going anywhere. Other people say, We either have a MySQL database already or a Postgres database, or we just want to stay on some sort of open standard. Man, we got to do a whole show on Superbase sometime soon. Yeah.

Yeah. Yeah. So I asked, like, what should I use? And it was probably 40% PlanetScale, 40% Supabase, and the rest of the 20% was scattered on the rest of the stuff that I have here. So I was, Like, Supabase and PlanetScale, they got that this kinda locked in. So let let's talk about them really quickly. Cloudflare has 2 solutions. They just rolled it out last week. D one Is there, SQL based database? It still is proprietary, but it is an SQL database.

And then they also have Cloudflare key key value storage. They've had that for a while as well. So you it kinda you think about, like, MySQL or IndexedDB. You wanna be able to start start key values.

And those things are both built for Cloudflare, which is serverless edge entirely. Right? The other one, AWS has two value 2, DynamoDB.

I used that one. I this is not my 1st hit counter I've created in the in the past.

I made a a hit counter that rendered to a PNG.

Oh, yeah. A long time ago.

I put that on begin.com

And I remember when you did that. That was Yeah. A fun idea. It got, like, half a 1000000 hits and didn't even stumble,

like, nothing, Which is amazing. I remember Brian Lewer, who runs begin, was like, we were watching that. We were wondering if we'd have to scale it up, but It handled it. No problem.

So that is a very good option. AWS DynamoDB. And then they have AWS Aurora, which is their Scalable SQL relational database.

Fauna, is another popular one. It's distributed, so I think they will distribute them around the world. It's SQL.

It's connectionless, which we talked about. You don't have to have a connection. There's no connection pooling. It's just request in, request out, and it has GraphQL built baked into it. So that seems like that that I think pretty sure this is all, proprietary, but it seems like a really good option.

Have you seen Fauna? Is I thought Fauna was like a graph database.

Let's see. No. It just says GraphQL. Okay. I was thinking that Fauna was, like,

some of the other graph databases that we've looked at. I don't think it is. Like, isn't Graph database just a database that points to other documents? Yeah.

Stores the data in a graph.

This just this seems like it's, Yeah. It's its own NoSQL. I don't see any word where it says graph database on their site. That's the only reason why it has, like, hesitate on that. Oh, yeah. Yeah. I See, that's like a lot of the other graph databases. Like, graph database, you know, and

big big They may have just taken that out of Their marketing as

well. Yeah.

Because, like, remember, we were like, what the heck is a graph? I know.

Remember that?

Sivana seems like a good Supabase seems like a, really good solution. So, Supabase is kind of like it's pretty much just open source Firebase, which is awesome. So they do real time. You can scale it up yourself.

You can. I'm pretty sure they host it. Yeah. They have pricing,

which seems pretty good. It's on a super base.

Yeah. Yeah. You can also host it yourself. I like that. I like companies like that. Century's like that as well. It's like, I'll pay you. Yeah. But I just like to know that I Could host them myself if I really wanted to. I just I agree. Yeah. Seriously.

You're not gonna lose the special sauce if you wanna host it yourself. Us. Next one is Neon at Neon dot tech,

serverless Postgres.

So they do it looks like they kinda do what, PlanetScale does, but in Postgres instead of my SQL.

So it seems like a pretty good option as well. They got some

really great design on this website.

Yeah.

It is

Really gorgeous. That is a very nice website. Oh, cool. Yeah, they did. They're doing an awesome, awesome job. Railway is another one that people were recommending. I think Railway is

a host.

It says you bring the code, we'll handle the rest. So they they are a host, a deployment integration database.

Did they do images as well? I'm curious.

Yeah. I actually tried out Railway before, and I found the experience to be really nice. But I I got After, like, a couple of months of being on Railway, I did get, like, a we had a security breach email, so it kinda made me a little bit concerned for them. But, Yeah. That was a while ago. So Oh, yeah? Oh, at least they sent it. Yeah. No. Oh, no. No kidding. Yeah. Because it's not about Yeah. This railway seems pretty cool. There's a a lot of companies in the space right now. When I used it, the, the interface was really nice, and the whole thing felt really good to use. So I I was a fan of Railway when I tried it. If you look at their investors, their investors are, some heavy hitters. Wes Guillermo,

Tom Preston Warner. Oh, yeah? Yeah. Awesome.

Next up, we have MongoDB Serverless.

So the MongoDB Atlas that actually Scott and I both use. They now offer a serverless offering, which essentially is instead of you us. Choosing the amount of resources you need. So in in my MongoDB, I have to log in and and choose how much RAM I need and how much space I need and whatnot. And, the MongoDB serverless offering essentially just scales up and down as you need it.

I'm assuming they also handle the connection pooling issue, for you as well. I have not looked into that, but quite a few people were recommending that as well.

Yeah. I haven't used the serverless version of that at all myself.

No. I I should I should give it a give it a shot. I don't think it will be all that much different from what I'm doing, which is kind of nice because you don't really have to we have lots of existing applications. And if you want to move them, you shouldn't have to change your too much database code. Right? Yeah. No kidding.

That that's the part that stresses me out the most. It's like, oh, I'd love to try some of this stuff with my existing infrastructure and then oh, yeah. Wait. That seems like a harder task than just hacking together a quick little demo. Yeah. Redis, Cassandra,

2 very popular NoSQL databases, that apparently work really well with serverless. And then we have Firebase on top of here, which has been around for Quite a while. So tons and tons of options. That's probably only half or or a quarter of the possible options that are out there, but it kind of gives you a good idea of There's lots of them out there. Some of the proprietary, some of them are not. Some of them are MySQL or sorry. Some of them are SQL based and some of them are, No SQL base.

Yeah. It also feels like this is a space that is pretty evolving right now, too. Yes. Yes, I agree. So

that's all I got for today. If you've got any tips on serverless databases, make sure you tweet us at syntaxfm. We'd love to hear especially if you've, like, converted,

Like a server app to serverless. I'd love to hear, like, what did you do about your database? Yeah. I'm very curious as well because, again, This is something I'm fairly ignorant about in general. So this this definitely cleared up a lot for me, Wes, in terms of, like, what are the issues there? Enrolling your own server pooling or connection pooling doesn't really sound that much fun to me so I I might be the type to look for One of these actual solutions rather than trying to do some sort of connection pulling on my own. Yeah.

I think if I were to do it today, I would pick something that was either Postgres or MySQL or MongoDB, so that I could just use my regular adapters and queries and stuff like that, but pick a service, a hosting service that will scale for me and do all the connection pooling.

Word. Cool. Well, thank you so much for for this.

I I've left smarter.

Awesome. Alright. Catch you later. Peace. Peace.

Head on over to syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player it. Or drop a review if you like this show.