Consider using D1 instead of DO storage

[cometkim]

Previously, as an implementation strategy for persistent state, I introduced DO and event sourcing.

Also described it may provide better flexibility. And at the time, D1 wasn't such a good option.

I changed my mind after seeing this announcement today.
https://blog.cloudflare.com/d1-turning-it-up-to-11/

It now JSON features and time travel recovery. A very reasonable pricing policy is also included.

What DO still does better is its lower access cost and actor model. It allows for more aggressive distribution model and elasticity if we don't want distributed transactions or something (indeed it is very difficult)

The SQL frontend definetely will provide better DX and operational convenience.

The only blocker is that it doesn't yet provide Rust bindings, but that will probably be there soon.

cloudflare/workers-rs#270

[kyoungduck]

I love D1

SQL is better interface

[FlareLine]

Great contribution considering the D1 implementation is now under review.

One question I would ask is whether it's useful keeping the option for DOS as a persistent storage mechanism in the documentation - I would argue that it's still a reasonably viable option?

[cometkim]

@FlareLine Assuming that most of the states we'll be dealing with are kept simple, DOs are still a useful option.

However, the main reason for choosing D1 is better maintainability. Using DOs needs careful migration strategy. It might be event sourcing, but it adds implementation complexity.

I don't think we need to use multiple tools for the same purpose.

Also JOIN might be useful at some points.