mattrobenolt

6 ms·

1.
Alloconda: Zig toolkit for writing CPython extensions(github.com)
3 points by mattrobenolt 9mo ago|0 comments
2.
by mattrobenolt 1y ago
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 IOPS available on the drives. Even if you c
3.
by mattrobenolt 1y ago
You can simply place your database in the same AWS or GCP region and the same AZs.
4.
by mattrobenolt 1y ago
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 your arguments are i
5.
by mattrobenolt 1y ago
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 impossible, the reality is that's v
6.
by mattrobenolt 1y ago
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 100% true, but I've never seen a RDBMS be able
7.
by mattrobenolt 1y ago
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 for the whole cluster.
8.
by mattrobenolt 1y ago
It's still AWS/GCP, but it uses instance types with local NVMes.
9.
by mattrobenolt 2y ago
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, Vitess already has to maintain this with it's interna
10.
PlanetScale: Global Replica Credentials(planetscale.com)
2 points by mattrobenolt 2y ago|0 comments
11.
by mattrobenolt 4y ago
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 hops may be between.
12.
by mattrobenolt 4y ago
Yup! There are a few caveats, but for the most part it'd be compatible. https://planetscale.com/docs/reference/mysql-compatibility
13.
by mattrobenolt 4y ago
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, lots of our customers and lots of use ca
14.
by mattrobenolt 4y ago
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 think it's particularly a "gotcha". HTTP is
15.
by mattrobenolt 4y ago
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 doesn't solve all the things we can improve by
16.
by mattrobenolt 4y ago
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 communicating between components. To me, HTTP sits i
17.
by mattrobenolt 4y ago
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 it stood up to a traditional mysql client. But you do yo
18.
by mattrobenolt 4y ago
Much love. <3
19.
by mattrobenolt 4y ago
Anything is possible with computers.
20.
by mattrobenolt 4y ago
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 all is the big win. I didn't anticipate that th
21.
by mattrobenolt 4y ago
> 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. (This could lead to potential deadlocks, but there are ways
22.
by mattrobenolt 4y ago
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 connection.
23.
by mattrobenolt 4y ago
Sorry about that.
24.
by mattrobenolt 4y ago
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 while it may be an edge case for you, it's not
25.
by mattrobenolt 4y ago
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 processes. Think PHP, and serverless environments,
26.
by mattrobenolt 4y ago
I have vaguely looked into it, but since we don't support it at PlanetScale and unlikely we will, it didn't seem worth it. It'd be hard to construct a practical test. Similarly, since support is so low, it didn't make a
27.
Faster MySQL with HTTP/3(planetscale.com)
185 points by mattrobenolt 4y ago|47 comments
28.
by mattrobenolt 4y ago
In our case, it's a bit more state than just a transaction ID, but the same concept applies. And yeah, to mirror the other comment, this isn't particularly something I'd consider a security issue. If an attacker has access to
29.
by mattrobenolt 4y ago
Correct. I would not recommend doing that. This is analogous to a database driver. It's raw access to the database.
30.
by mattrobenolt 4y ago
It's a good chunk of it, but is a lot more suitable for public consumption.

More ›