PlanetScale Portals: Read-only regions | Hacker News Reader

PlanetScale Portals: Read-only regions

planetscale.com

71 pointsfideloper15 comments

Looks like a nice launch for apps that need lower latency for reads. A noticeable omission from the blog post is how these replicas impact consistency. Won't reads from read-only regions have a weaker consistency than you typically get with Vitess/PlanetScale? I'm guessing weaker than read-your-writes.

Not directly related, I've been really tempted by all these exciting new database offerings.. PlanetScale, CockroachDB, FaunaDB.. but there don't seem to be any solid (node.js) background job queue libraries that support them. I really want to take advantage of these low dev-ops high availability offerings, but I don't want to have to tack Redis onto my stack just so I can use BullMQ, with data persistence and robustness as a bit of an afterthought.

And I don't want to roll my own because it's not a trivial thing to solve, especially with stall detection etc.

I'd love to just have one robust data-store.

Am I missing something?

Assuming your async job workload isn't massive, you could use job systems that have database backed queues?

That's exactly what I'm looking for, I'm just not seeing the libraries.

Yeah... I wish Temporal had FaunaDB support. Seems like a great fit for globally distributed jobs.

Temporal sounds _very_ interesting, hadn't heard of it before..

Edit: It sounds like temporal supports CockroachDB

It could work in theory, since it's supposed to be compatible with Postgres, but last time I checked they don't test against it, and it's not anywhere close to 100% identical (https://www.cockroachlabs.com/docs/v22.1/postgresql-compatib...), so I'm personally not too comfortable relying on it for production workloads.

Things might have changed since though, I'd try asking folks in the forums to hear their experiences with it before diving in. Would be awesome if this setup worked well though!

I personally prefer Fauna from an operational perspective since it's a 0-maintenance SaaS that scales pricing with usage with a generous free tier, but it's probably unlikely to be supported anytime soon.

Any type of job queue that can use MySQL for scheduling state support should work just fine with PlanetScale.

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.

The automatic routing via Rails is very cool. I may try to work that up in Django as well.

This would be such a nice addition to apps deployed on fly.io

Author here. Funny you mentioned that, we worked with the Fly.io team to get this guide created for just that: https://fly.io/docs/app-guides/planetscale/

(I swear we didn't plan this response.)

Very cool; will try it out. Thanks!

https://twitter.com/flydotio/status/1529117954931101700

What kind of consistency guarantees does this offer?

Reply on news.ycombinator.com