Viewing profile — mattrobenolt

Right, but I think you're kinda missing a lot of the tangible benefits here. This IMO is just reinforcing the idea of "unlimited" IOPS. You can't physically use the totality of IOP…

You can simply place your database in the same AWS or GCP region and the same AZs.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ssd-inst... Not all AWS instance types support NVMe drives. It's not the same as normal attached storage. I'm not really sure yo…

It's more than just shutting down. You'd have to have an actual failure. Data isn't lost on a simple restart. It'd require 3 nodes to die in 3 different AZs. While that's not impos…

Unlimited in this context just means you're going to be CPU limited before you hit limits on IOPS. It'd be technically not possible to be bottlenecked on IOPS. That might not be 10…

We deal with this by always running 3 nodes in a cluster, one per AZ, and strong backup/restore processes. So yes, the data per-node is ephemeral, but it is redundant and durable f…

It's still AWS/GCP, but it uses instance types with local NVMes.

Hi there, fundamentally this is a bit challenging against something vanilla Postgres or MySQL to bolt on since the connection itself is stateful. Because of the Vitess layer we use…

We're a service provider. As a client and customer, you connect to us as a third party service. You don't control our uptime or connectivity. Nor do you control whatever network ho…

Yup! There are a few caveats, but for the most part it'd be compatible. https://planetscale.com/docs/reference/mysql-compatibility

Mostly agree here. I don't think in practice, you'd default want to use HTTP/3. I think as technology, it's still just very immature for reasons you mentioned. In our case though, …

In theory. In practice nothing implements this. But in any case, even if your client did support this and the server supported it, we still need HTTP for other things. I don't thin…

It helps some cases for sure and what I'd strongly recommend in practice. Connection pooling isn't always a viable option depending on the application though. Connection pooling do…

Also ever heard of gRPC? It's pretty popular and widely used. Whether you like it or not or whether it's the most optimal in theory, in practice HTTP is heavily heavily used for co…

Check your bias. This was clearly communicated as an experiment with surprising results. In some contexts, we don't have a choice but to support HTTP. So simply wanted to see how i…

Much love. <3

Anything is possible with computers.

My apologies for not meeting your bar. I guess you missed the parts where it's faster in a lot of other cases too, and not slower in any. To me, the fact that it's not slower at al…

> 1) use persistent connections, let the OS handle them and tweak it to allow (both connecting server and mysql server). And never close the connection on the application side. (Th…

The tests cover both cases if you read. But either way, yes, that's fundamentally a benefit of being able to use HTTP. We can multiplex multiple sessions over one underlying connec…

Sorry about that.

I'm not a PHP expert, so I don't know the landscape there fully. I do know our customer complaints and can say people care about cold start times in the PHP space and others. So wh…

Maybe in your case, but not always. But I do explicitly call out that I intentionally wanted a test of a "cold start". This is extremely relevant for short lived applications and p…