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 PlanetScale since shortly after they went GA and I've been very happy so far. Cheaper than Aurora Serverless, less hassle, and the branching feature is super cool. Zero-downtime deploys, with rollback support, feel magical.

Please forgive my ignorance. Is it right if I say the password seems to be available on the client side?

import { connect } from '@planetscale/database'

const config = { host: '<host>', username: '<user>', password: '<password>' }

https://github.com/planetscale/database-js

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?

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.

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.

Please consider using a custom string interpolation function to sanitize SQL, not an additional array of parameters. See styled components for inspiration.

do people want a SQL DB over HTTP?

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

This is really cool, but you missed Deno. I have a hunch this would mix well with Fresh

HUGE launch so hyped

While this is cool tech and convenient, I worry about run-away costs and what happens if the company goes down? Seems like a LOT of risk.

It's 90% there... but not allowing foreign keys [1] (=cascading delete) means that this solution becomes equal with DynamoDB (Serverless + Scale to 0 as well) because products will either be built for it from day one or never support it with a full fledged DB server instance that is 100% up in mind. Unfortunately, didn't find a lot in-between.

[1] https://planetscale.com/docs/learn/operating-without-foreign...

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 and I enjoy using it. One downside to Prisma is the DB "engine" is a arch-specific (obviously) binary that is pretty hefty. I want to say ~50MB. That can be a killer in serverless but I was able to work around it without much issue. If I ever wanted to dive into the world of Lambda layers I could probably move it into it's own later (however that still counts towards your max lambda size).

Our beta for this is pretty stable. The only real instabilities are around the underlying APIs we use, which is part of why we're not ready to document it just yet.

But the underlying tech is exactly the same as we use for handling traditional MySQL connections, so there isn't anything to fear.

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

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 that come with HTTP. Also, in this case, the payload is JSON, both on the request and response, which is going to be slightly more bulky than the payloads over the MySQL protocol.

So where things get interesting is the real world performance implications. Networks and CPUs are really fast. HTTP has been extremely scrutinized and JSON as well. While they are admittedly not the most efficient standards, they are used so heavily and parsers are heavily optimized for these protocols.

Mixing in modern TLS 1.3 with modern ciphers, which is something you're very unlikely to get with a traditional MySQL client, we can achieve a much faster first connection time. Pairing with modern ciphers that are demanded for TLS 1.3, and the transport itself can be significantly faster than a slower cipher. This isn't the best comparison since typically you're using MySQL without TLS, but when talking to a service provider like us, we require it for obvious reasons.

Next, with HTTP, we get to leverage compression. In our case, we can use browser level native compression with gzip, or if using something server side, we support compressions like snappy. Combine something like gzip or snappy with HTTP/2 now, and given that the bulk of a query result is typically the result itself, and not the protocol, compression can make up a decent amount of the difference. Again, I'm being hand wavy since every query pattern and results are going to be wildly different based on your data, so it's not anything fair to say "this is x% more or less efficient."

And lastly, with HTTP, especially HTTP/2, we can multiplex connections. So similar to the gains with TLS 1.3, you can do many many concurrent database sessions across 1 actual TCP connection with HTTP/2. And similarly to TLS 1.3, the cost here is in connection timings, and management of a connection pool. You don't need a pool of connections on the client, so your startup times can be reduced.

As a stretch goal, HTTP/3 (with QUIC) is in the crosshairs, which should eliminate some more transport cost since it uses UDP rather than TCP. My hunch is all of this combined together, an optimized driver leveraging HTTP/3 might beat out a MySQL client overall. Time will tell though!

So there's no simple answer here, everything has tradeoffs. :)