Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The PlanetScale serverless driver for JavaScript

planetscale.com

Post reply on HN
Print view View original

21–30 of 56 posts

Re: The PlanetScale serverless driver for JavaScript

#21

Post by gsanderson »

k__ wrote: post #10
gsanderson wrote: post #8

This is great! Potentially the missing piece in the world of "serverless": a serverless SQL database accessible over HTTP with no minimum price. I saw AWS Aurora has a Data API but currently that does have a minimum monthly cost. Fauna is possibly the closest, but that appears to involve translating SQL to its FQL. How stable is the beta?

But it doesn't seem to habe serverless/pay-as-you-go pricing.

I believe it does. From their pricing page, beyond the included quota it is $1 per billion reads and $1.50 per million writes

Re: The PlanetScale serverless driver for JavaScript

#22

Post by tbarn »

_ben_ wrote: post #5
alexcroox wrote: post #2

This is huge for me. I went down the path of trying to build an entire API on CF Workers and the biggest stumbling block was no easy access to external relational databases due to a lack of v8 compatible connectors. This was before the D1 announcement of course.

Does CF workers support TCP yet?

They still require external connections to be made over HTTP and not other networking protocols. This is part of why this new driver is useful. Before today, it would have been impossible to use PlanetScale directly from a worker without it.

Re: The PlanetScale serverless driver for JavaScript

#25

Post by joshstrange »

mattrobenolt wrote: post #18
joshstrange wrote: post #15

Very cool and lightweight way to talk to PlanetScale but for now I'll stick with Prisma. Prisma is much heavier (engine weighs in at ~50MB) and that can be a non-starter for serverless in some cases but it works for me on AWS Lambda. The nice thing about PlanetScale is you get nearly unlimited connections (soft limit of like 250K IIRC) so making 1 connection per active lambda isn't a problem at all. I've been using P…

We didn't talk much about this yet, but the underlying tech for this will help you within Lambda too reduce latency even over normal MySQL. This specifically is targeting environments where a MySQL client isn't able to run.

> This specifically is targeting environments where a MySQL client isn't able to run.

Oh, absolutely and I didn't mean to imply it wasn't useful, I was just saying I went down the Prisma path and will be sticking with that. Even so I'm glad this exists for times that I don't need the full weight/power of Prisma but do want to talk to a PlanetScale DB.

Re: The PlanetScale serverless driver for JavaScript

#26

Post by gsanderson »

joshstrange wrote: post #14
gsanderson wrote: post #8

This is great! Potentially the missing piece in the world of "serverless": a serverless SQL database accessible over HTTP with no minimum price. I saw AWS Aurora has a Data API but currently that does have a minimum monthly cost. Fauna is possibly the closest, but that appears to involve translating SQL to its FQL. How stable is the beta?

I mean I'm using PlanetScale with Prisma ORM on AWS Lambda right now without issue. Unlike many DB providers, PlanetScale supports nearly unlimited connections. I think I saw in their docs they have a soft-limit of something like 250K connections. I used Aurora Data API before moving off Aurora Serverless (insane pricing) to Prisma and PlanetScale, I don't think I'd go back to the HTTP API as Prisma works very well a…

I agree about Aurora Serverless pricing!

Yeah, I think this new thing would be less useful for Lambda as that does support TCP connections. However a HTTP API is required for e.g Cloudflare Workers where you can't create a normal MySQL client. I think that's where this could shine.

Re: The PlanetScale serverless driver for JavaScript

#28

Post by mattrobenolt »

joshstrange wrote: post #25
mattrobenolt wrote: post #18

Earlier quoted context omitted.

We didn't talk much about this yet, but the underlying tech for this will help you within Lambda too reduce latency even over normal MySQL. This specifically is targeting environments where a MySQL client isn't able to run.

> This specifically is targeting environments where a MySQL client isn't able to run. Oh, absolutely and I didn't mean to imply it wasn't useful, I was just saying I went down the Prisma path and will be sticking with that. Even so I'm glad this exists for times that I don't need the full weight/power of Prisma but do want to talk to a PlanetScale DB.

I went down the Prisma path investigating JavaScript ORMs, and... I have opinions. :)

I feel that what we have would be useful within a Prisma context, but given their complexity and how Prisma works, it's likely not very practical with their "engine".

Re: The PlanetScale serverless driver for JavaScript

#29

Post by mattrobenolt »

rsweeney21 wrote: post #27

Has anyone tested edge functions + planetscale (or similar) vs edge functions + a database read replica also located at the edge? It seems like you lose most of the benefit of your code running at the edge if your database is still in an AWS region.

:see_no_evil: This is an obvious next step for us.

Re: The PlanetScale serverless driver for JavaScript

#30

Post by brundolf »

mattrobenolt wrote: post #9
brundolf wrote: post #6

Curious what the performance impact is of replacing TCP with HTTP for this kind of thing

Great question! Author of a lot of the infrastructure surrounding this here. I plan on following up with a more technical deep dive on some of these aspects, but it's quite a bit hard to do a 1:1 comparison. While, obviously, HTTP also uses TCP, I'm going to assume you're asking more about the binary MySQL protocol vs HTTP. On the surface, yes, HTTP is going to have more overhead with headers and the other aspects th…

Wow, thanks for the thorough response!

That's awesome, I was assuming a sizable overhead (even if it is for a sizable benefit). But I can see how lots of factors contribute to closing the gap, and HTTP/3 might even be a negative overhead since it almost cuts out a protocol layer by stepping down to UDP.

Thanks again!

Post reply on HN