derekperkins

The password confirmation box isn't marked up so that Chrome will autofill a suggested password

Have you looked at Planetscale?

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's likely that Planetscale will eventually provide a provisioned billing model, similar to DynamoDB. Then you can choose between scalable usage based pricing or less flexible flat rate pricing. Either way, innovating different billing models for RDBMS is a win.

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 solid and I love their development philosophies. This is a technology to bet on.

No affiliation, just a fan

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 in large part because of their billing model. They would have never considered a SQL database before because of the fixed cost.

Those nosql options (probably the most popular in the world) also have the issue that row sizes are different, and if you're super cost conscious, you can change your architecture to take advantage of it. For example with Planetscale, you could store a lot more in JSON columns instead of other tables to reduce costs if that was your primary objective.

Is your frustration that you'd like to use Planetscale or a managed Vitess, but you are worried about locking yourself into a pricing model that you don't think will work for you?

"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. Some of them also have pre-provisioned options, and it seems likely that Planetscale will probably end up doing something similar.

https://aws.amazon.com/dynamodb/pricing/

https://firebase.google.com/docs/firestore/pricing

https://cloud.google.com/bigquery/pricing#on_demand_pricing

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 often a customer/tenant id, and it's rare in practice that you will be performing cross-customer transactions.

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://vitess.io/docs/13.0/user-guides/vschema-guide/advanc...

When you're choosing your sharding keys, you want to design it where the bulk of your operations happen on a single shard, often a tenant/customer id. That guarantees that all customer data lands on a single shard, with FKs across every table you want.

We're running on ~40 shards across 6 keyspaces, and there are very few cases where we can't use FKs.

Vitess supports PITR, so I'm sure it'll land in Planetscale sooner or later

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 willing to give up OSC. We've been running Vitess for years with that trade-off and it works great.

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 database with orphaned rows and insistent data.

That being said, depending on the data you're working with, you may be fine with that trade-off.

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 destination queues

Our whole stack is built on it and we process ~1B messages / day. https://vitess.io/docs/13.0/reference/features/messaging/

Hopefully Planetscale sees fit to expose that functionality in the future, and to be honest, since all the interaction with it is over the MySQL protocol, it's very possible that it would just work today.

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

You clearly didn't read the article, that's what the whole thing discusses

This is a great article going into more specifics. https://brandur.org/idempotency-keys

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.

Great description

You might coordinate with the Vitess team to see if there's any interest in sharing code on the parser.

I mentioned this in a top level comment, but YouTube already open sourced their version of it in Vitess, with almost identical characteristics.

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 almost identical.

https://vitess.io/docs/12.0/reference/features/messaging/

I couldn't get through the article on mobile, the text was about 3x too large

> 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.

> MySQL will permit this statement to execute

That was disabled by default in 5.7, 6 years ago. I totally agree that it should have been turned on by default earlier, but isn't a valid criticism of modern MySQL.

> Simple date math in SELECTS would result in idiocy

I've never tried that before, and it looks like that hasn't changed. No idea why that doesn't throw an error.

select date('2021-11-01') - date('2021-10-01'), datediff(date('2021-11-01'), date('2021-10-01'))

results in: 100, 31

> Schema changes escaped from transactions

Since 8.0 (April 2018), schema changes are transactional, but you can't include DML changes in the same transaction as a DDL. I haven't found that to be a dealbreaker, but would certainly be nice to have.

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 article are still valid, including UTF-8 handling. The author themselves put a disclaimer at the top of the article stating as much. Not quite sure what you mean by "definition of a key" or "struggled with functional dependencies", so I can't speak to those directly.

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.

FWIW, that migration wasn't because they chose to move to Spanner, they were required to.

There's a Go port that we're pretty happy with.

Since the obvious comparison is to react router, here's a link to a table comparison https://react-location.tanstack.com/comparison

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.

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 materialized views that aren't possible with MySQL. Finally, Vitess Messaging is an awesome way to do async work, allowing for transaction guarantees where you can ack a message, do data work, then add to another queue, all without having to deal with weird side effects.

Architected correctly, there's minimal need for cross-shard foreign keys. A common use case is sharding by tenant/customer id, which means that all records for a single customer live on a single shard. That lets you have all the FKs that you want, and any operations for that customer happen on a single shard, which gives you maximum speed and transactional guarantees.