lizztheblizz

8 ms·

1.
by lizztheblizz 2y ago
Hi there, PS employee here. In AWS, the instance types backing our Metal class are currently in the following families: r6id, i4i, i3en and i7ie. We're deploying across multiple clouds, and our "Metal" product designation ha
2.
by lizztheblizz 4y ago
Lambda was a means to an end for us here, and we're not specifically endorsing its use in _this_ way. Our goal was explicitly to test our ability to handle many parallel connections, and to observe what that looked like from different
3.
by lizztheblizz 4y ago
Article author here. I fully endorse Aaron's correction and appreciate the call-out. For context: I initially wrote this paragraph to include more flavor and history around crash recovery challenges with relational databases, implying
4.
by lizztheblizz 4y ago
So, disclaimer, I am not an Amazon Billing wizard, but given that we ran the Lambdas from an isolated sub account, I can be particularly certain that I was able to filter this down accurately. We hit the one million connections total probab
5.
by lizztheblizz 4y ago
Absolutely agreed. As others have already pointed out, there is no underlying implication of preference to this kind of application architecture. Since we do run an actual DBaaS, one of our main internal goals in running these experiments w
6.
by lizztheblizz 4y ago
Article author here, interesting question! We didn't run into that issue, explicitly. Our setup was effectively as follows: - AWS Lambda functions being spawned in us-east-1, from a separate AWS sub account. - Connections were all made
7.
by lizztheblizz 5y ago
I don't have nearly the experience in Postgres environments to have seen the same level of real-world impact there, but a quick search presents me with the following documentation, which seems to indicate mostly similar performance cha
8.
by lizztheblizz 5y ago
Depends. Have any examples of "normal" sharded MySQL databases? EDIT: To clarify, sharding is not a standard feature included in Community Edition MySQL. Over the years, there have been various Oracle-initiated attempts at providi
9.
by lizztheblizz 5y ago
Give it a shot, because the current implementation specifically side steps the need for that full copy, and does let you test functionally against fully up-to-date production data. You're right, though, it doesn't cover all of tho
10.
by lizztheblizz 5y ago
12+ years of massive scale production use for Vitess and 26+ years of hardening for MySQL and InnoDB. PlanetScale adds some (imho) great features on top of that, but it's standing on the shoulders of giants that have proven themselves
11.
by lizztheblizz 5y ago
Already on it. :) https://vitess.io/docs/reference/vreplication/vreplication/
12.
by lizztheblizz 5y ago
To be clear, this is not a Vitess/PlanetScale-specific opinion or choice. Foreign key constraints are a bit of a controversial topic in large-scale MySQL environments in general, which is the greater context in which this design decisi
13.
by lizztheblizz 5y ago
Vitess' compatibility with MySQL has made major leaps in the past couple of versions and the team has started focusing on locking in ongoing compatibility with various popular development frameworks. You can find those here, and more a
14.
by lizztheblizz 5y ago
That is exactly what we _do_ support. Our team includes the original developer of gh-ost for MySQL, which has been built to execute these kinds of massive changes at scale at GitHub. We've integrated it tightly with Vitess. Once your b
15.
by lizztheblizz 5y ago
The "ease" we used to refer to in Vitess primarily relates to its interaction with the application side, where it basically presents itself as "one big MySQL datastore". It uses a standard MySQL connector, and in general
16.
by lizztheblizz 5y ago
It's closer to your original assumption than your second. Branching relies on vreplication, and it does actually allow you to develop multiple versions of your schema against your full production dataset. The "magic" is a pow
17.
by lizztheblizz 5y ago
This is monthly. :)