This is super powerful, been playing around with the previous releases for the past few days. It works really well, but still needs a few dx tweaks to make it performant for large applications. You have to watch the callbacks yourself to update slices of state and unless your app is small enough that the whole thing can re-render every update.

That being said, I love everything automerge is doing and hope this pace will keep up!

This looks incredible, could see this approach revolutionizing so many industries.

Solar followers have been around for decades and do not need ML or complex models.

Thank you! RL will eat the world. I'm applying it to batteries optimization next

this is not my field, but you couldn't just have it orient to point of brightest intensity?

You certainly could, but that doesn't entirely account for shading / system degradation / site-specific diffuse light opportunities (consider a huge amount of light reflecting off the side of a mountain at some time of day). Those are both really difficult and time-intensive to model for, so there's a desire to have an AI that can simply learn those things specific to the system it's optimizing without humans having to do it. I see the larger impact of RL as scaling humanity's problem solving capability. If we have to use N human hours per installation to get to 97% optimality per installation but RL can use N/10000000 per installation to get to 95%, we could free up all those N human hours for things that RL still struggles with. Just my 2 cents though, it's a very fair question

Yeah but that requires knowing control theory rather than “learning” it.

Control theory is better if you know what you’re doing. ML is technical debt for sure.

I'm more and more convinced of this. Control theory appears to be like lightsabers, "a refined weapon for a more civilized age". It's really unfortunately that the controls literature is so opaque.

>> Control theory is better if you know what you’re doing.

The "if you know what you’re doing" here does not refer to the ability to understand control theory. It means that if you know the underlying dynamics, there is mathematically nothing better than controlling those dynamics. Flying a plane, oscillating a circuit, etc. are all things we can do very well without ML because we have exact models of the physical phenomena. Playing chess has no dynamics, control theory is useless. Anything where the dynamics are not "nice" differential equations, ML is probably easier at learning the dynamics than coming up with an ansatz.

There are areas of control theory where you can learn the dynamics ("adaptive control"). The advantage over RL is that in control theory, you generally assume the dynamics are described by differential equations (sometimes difference equations), not by Markov decision processes. MDPs are more general, but basically any physical mechanism you're going to control doesn't need that generality.

There is a surprising amount of structure imposed by the assumption that the dynamics are differential equations, even if you don't know what the differential equations look like. As a consequence, adaptive control laws generally converge a lot faster (like, orders of magnitude faster) than MDP-based RL approaches on the same system being controlled.

The other advantage is that you can prove stability and in some cases have an idea of your performance margin with control theory. THis is important if you eg want your system to receive any sort of accreditation or if you want to fit it into the systems engineering of a more complex system. There's a reason autopilots don't use RL, and it isn't that RL can't be made to work. It's that you can't rigorously prove how robust the RL policy is to changes in the airplane dynamics.

I worked on the security team at GitHub, this was a long standing part of how git works. GitHub allows users to verify commits via GPG signatures to prove that they committed something but it doesn't work for proving a negative, that you did not commit something.

We got so many of these submissions which are clearly called out in the rules/scope, usually the people who don't read the rules don't find anything useful. ¯\_(ツ)_/¯

Obviously anyone can attach any email to any commit, but why does the frontend UI work like this:

    gh_profile = get_profile_with_email(commit_email)

and not this?

    gh_profile = get_profile_with_email(commit_email)
    if not gh_profile.has_verified_email_ownership(commit_email):
      return null

I’ve wanted this for so long. We proxy our static marketing site just so we can check headers for auth and redirect you to the dashboard if you’re signed in.

Happy to help :)

Haha yep, I was like wait I'm used to getting feedback from the system telling me I messed up and this I barley noticed. PlanetScale has Query Statistics that are really useful for spotting slow queries but don't expose the "rows read" so you can't really tie this view back to billing. I think they're aware of this though and might expose that information.

I'm so curious, so you maintain Vitess but don't use it personally?

I do use it in production and have for years, just not the online schema changes. It's fantastic and FKs are supported in a single shard, which we use heavily.

If you take out online schema changes and sharding, what's the use case for vitess?

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.

If you take sharding out what's the point of using anything other than a normal sql database?

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.

Thanks Sam! As mentioned in the post, the PlantScale team was quick to credit our account for the overages and help us figure out what was going on. I'm personally super bullish on PlanetScale!

With any new product there will be tradeoffs and rough edges but the positives, like easy migrations and database branches have definitely outweighed any difficulties.

Kudos for being open about your mistakes.

Could you share a little bit about what your thought process was in general when picking a database technology?

You call out "easy migrations and database branches" outweighing other quirks, so some pros and cons weighing must've happened :)

Is it easy, for example, to test things in your dev environment with realistic amounts of data, and to get an understanding of how the queries will execute, etc? These seem somewhat basic, and would've probably caught this (also kinda basic, sorry :) problem early. (As in discovering "why is this query that should be a few ms with an index lookup taking so long?" early on)

Thanks! The decision making process was pretty unsophisticated tbh. Basically I spent the last couple years working at GitHub as a security engineer and had been pretty comfortable with MySQL so wanted to stick with that. I had heard from our database team how annoying migrations were and I had previously locked a postgres database multiple times in production trying to deploy a migration, so MySQL + safe migrations + some of the best engineers I've worked with pouring all their time into PlanetScale, made a ton of sense. So basically a combination of proven underlying tech + believing in the team.

The migration workflow is really cool, basically when we create a PR we branch our production database and apply any migrations that are included in that PR and then that branch is used in our per-PR review environment. (Just Heroku Review Apps), then when we merge the PR, we also merge the deploy request in PlanetScale. Database branching is a super powerful concept once you've leaned into it.

We don't really do any sort of load testing in a dev environment. We have one customer who is also a co-founder of our company so we just deploy whatever changes we're unsure about (after automated testing) to his application and see what happens. If anything looks off in Grafana we'll make take a look but it's usually "good enough" or "totally broken", very rarely do we take time to make something 25% better if it already works. The time to fix vs speed of shipping features tradeoff doesn't make sense for us.

In this specific case, the query was taking place in a background job so 10ms - 500ms didn't really matter to us so we didn't really measure the timing, if we had we may have noticed it was slow but kinda a testament to PlanetScale that we didn't even notice ;)

Thanks for the background :)

Lock behaviour of migrations are indeed very important to be aware of.

Braintree (which are heavy Postgres users) have a pretty good post on that - https://medium.com/paypal-tech/postgresql-at-scale-database-...

We are so glad to have you as customers and I can't wait to partner as you grow to mega scale.

We're using Clickhouse to power our in-product analytics. It's awesome but would love a managed service b/c it definitely requires a bit of management overhead. Super excited about this announcement!

Check out Altinity.Cloud. It's managed and works today.

Disclaimer: I work for Altinity, which operates the Altinity.Cloud service.