5 ms·

PlanetScale Portals: Read-only regions

71 points by fideloper 4y ago

stalluri 4y ago
This would be such a nice addition to apps deployed on fly.io
- tbarn 4y ago
  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/ https://fly.io/docs/app-guides/planetscale/ (I swear we didn't plan this response.)
  - stalluri 4y ago
    Very cool; will try it out. Thanks!
- deleted 4y ago
  [deleted]
- PKop 4y ago
  https://twitter.com/flydotio/status/1529117954931101700 https://twitter.com/flydotio/status/1529117954931101700
- deleted 4y ago
  [deleted]
epberry 4y ago
The automatic routing via Rails is very cool. I may try to work that up in Django as well.
rubiquity 4y ago
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.
johtso 4y ago
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?
- jai_ 4y ago
  Assuming your async job workload isn't massive, you could use job systems that have database backed queues?
  - johtso 4y ago
    That's exactly what I'm looking for, I'm just not seeing the libraries.
- lewisl9029 4y ago
  Yeah... I wish Temporal had FaunaDB support. Seems like a great fit for globally distributed jobs.
  - johtso 4y ago
    Temporal sounds _very_ interesting, hadn't heard of it before.. Edit: It sounds like temporal supports CockroachDB
    - lewisl9029 4y ago
      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-compatibility.html 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.
kdkeyser 4y ago
What kind of consistency guarantees does this offer?

71 points by fideloper 4y ago

stalluri 4y ago

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

tbarn 4y ago
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/ https://fly.io/docs/app-guides/planetscale/ (I swear we didn't plan this response.)
- stalluri 4y ago
  Very cool; will try it out. Thanks!
deleted 4y ago
[deleted]
PKop 4y ago
https://twitter.com/flydotio/status/1529117954931101700 https://twitter.com/flydotio/status/1529117954931101700
deleted 4y ago
[deleted]

epberry 4y ago

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

rubiquity 4y ago

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.

johtso 4y ago

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?

jai_ 4y ago
Assuming your async job workload isn't massive, you could use job systems that have database backed queues?
- johtso 4y ago
  That's exactly what I'm looking for, I'm just not seeing the libraries.
lewisl9029 4y ago
Yeah... I wish Temporal had FaunaDB support. Seems like a great fit for globally distributed jobs.
- johtso 4y ago
  Temporal sounds _very_ interesting, hadn't heard of it before.. Edit: It sounds like temporal supports CockroachDB
  - lewisl9029 4y ago
    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-compatibility.html 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.

kdkeyser 4y ago

What kind of consistency guarantees does this offer?