derekperkins

9 ms·

61.
by derekperkins 4y ago
Vitess runs on actual MySQL, it's not just MySQL protocol compatible, so it's definitely closer. There aren't many queries you can't run on Vitess for a single shard, though distributed / multi-shard queries have mo
62.
by derekperkins 4y ago
The password confirmation box isn't marked up so that Chrome will autofill a suggested password
63.
by derekperkins 4y ago
Have you looked at Planetscale?
64.
by derekperkins 4y ago
Either you have an existing db running and check the metrics, or you don't have a workload to move and you can just try it out from scratch. You can always migrate away if the billing model doesn't work for you. Alternatively, it&
65.
by derekperkins 4y ago
Buf has done an amazing job simplifying the whole proto generation process, and now they're at it again, making gRPC easier to deal with. I've been using buf for years now and am excited to dive into connect! The team is rock soli
66.
by derekperkins 4y ago
The point is that the market has shown there is a huge appetite for alternative database billing models other than a fixed cost per month. From my limited personal interactions, I'm aware of 10-20 developers who are using Planetscale i
67.
by derekperkins 4y ago
"real cloud providers" most definitely charge based on rows read/written. Many startups / side projects choose the on-demand billing model because they don't want a fixed $x / mo when they don't need it. S
68.
by derekperkins 4y ago
In a production environment with well architected sharding, that rarely comes up in practice. It will be designed so that 99% of your operations happen on a single shard, both for performance and for transactional guarantees. That's of
69.
by derekperkins 4y ago
That's a different problem also solvable with Vitess. For those smaller tables, you can define them as a reference table, then have the same rows on every shard, so you can continue to have FKs to all of those. https://vites
70.
by derekperkins 4y ago
Vitess supports PITR, so I'm sure it'll land in Planetscale sooner or later
71.
by derekperkins 4y ago
Vitess, the underlying tech, only disallows FKs if you use online schema changes. They have to be on the same logical shard, and it just uses standard MySQL FKs. Hopefully Planetscale allows them in the future, as long as you're willin
72.
by derekperkins 4y ago
Strongly disagree. They allow you to declaratively say what data is allowed. No system where devs write code is going to be infallible, no matter how much people want it to be true. Show me a database without FKs and I'll show you a da
73.
by derekperkins 4y ago
Vitess, the underlying technology for Planetscale, does natively support messaging. It's pretty awesome because you can rely on native MySQL transactions to atomically: - Normal database work - Ack source message - Add N messages to N
74.
by derekperkins 4y ago
Most relational databases are fast enough for smaller key/value. Replace key/value with a blob store (still technically k/v) and I'm onboard
75.
by derekperkins 5y ago
You clearly didn't read the article, that's what the whole thing discusses
76.
by derekperkins 5y ago
This is a great article going into more specifics. https://brandur.org/idempotency-keys
77.
by derekperkins 5y ago
Then anyone inside your network has unrestricted access. That's why almost all security innovation and adoption is moving away from trusted boundaries. It can still play a role, in conjunction with other layers.
78.
by derekperkins 5y ago
Great description
79.
by derekperkins 5y ago
You might coordinate with the Vitess team to see if there's any interest in sharing code on the parser.
80.
by derekperkins 5y ago
I mentioned this in a top level comment, but YouTube already open sourced their version of it in Vitess, with almost identical characteristics.
81.
by derekperkins 5y ago
You can already get almost the exact same functionality via Vitess Messaging, also built on MySQL and HA across regions, which has been tested at YouTube scale. Vitess doesn't support ordered messages, but otherwise the architecture is
82.
by derekperkins 5y ago
I couldn't get through the article on mobile, the text was about 3x too large
83.
by derekperkins 5y ago
> it creates an index; it does not "create" a "key" I'm still not sure what you mean. By key, do you mean a unique key? With some quick searching, I'm not finding any difference in the Postgres docs. > My
84.
by derekperkins 5y ago
Postgres is a great choice too, and for most intents and purposes, Postgres or MySQL is the correct default choice for a database, so I'm not trying to persuade you to switch back. Just clarifying that almost none of the points in that
85.
by derekperkins 5y ago
As with most similar rants against the earlier days of MySQL, the majority of these points are based on old versions and don't reflect how things have been for almost a decade.
86.
by derekperkins 5y ago
FWIW, that migration wasn't because they chose to move to Spanner, they were required to.
87.
by derekperkins 5y ago
There's a Go port that we're pretty happy with.
88.
by derekperkins 5y ago
Since the obvious comparison is to react router, here's a link to a table comparison https://react-location.tanstack.com/comparison
89.
by derekperkins 5y ago
You ask them to fix the commit message. Every git GUI should support that by now, so it should be a 1 minute fix, even for junior devs.
90.
by derekperkins 5y ago
Vitess offers a lot of quality of life improvements over stock MySQL, including built-in backups to S3/GCS, managed replication, plus soon to be auto-failover detection. Additionally, with vreplication, you can do some pretty powerful

More ›