Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

* I saw your benchmark page at https://planetscale.com/benchmarks/aurora ; do you have something similar for Aurora Serverless?

* Do you support something like Aurora Fast Cloning (whether a true CoW fast clone or detaching a replica _without_ promoting it into its own cluster / branch with its own replicas, incurring cost)?

* Can PlanetScale Postgres set `max_standby_streaming_delay` to an indefinite amount?

* The equivalent of Aurora blue/green would be to make a branch and then switch branches, right?



it should be pretty much the same for aurora serverless and likely even cheaper. we see some astronomically expensive auorora serverless bills.

We have not made max_standby_streaming_delay configurable yet. What's your use case?

I don't fully parse your question about blue/green. can you expand your question please? is this for online updrades?


> I don't fully parse your question about blue/green. can you expand your question please? is this for online updrades?

Online upgrade or migration DDL - both use cases. I think Amazon's blue/green is effectively the same thing as your "branch-and-commit" strategy for schema migration. I was just looking for whether there's a significant difference.

> We have not made max_standby_streaming_delay configurable yet. What's your use case?

This goes with

>> Do you support something like Aurora Fast Cloning (whether a true CoW fast clone or detaching a replica _without_ promoting it into its own cluster / branch with its own replicas, incurring cost)?

The use case is mixing transaction processing and long-running queries/analytics in the same database using read replicas. The easiest way to do this in a native Postgres cluster is by using a "soft-real-time" read-replica with max_standby_streaming_delay set to `-1`, which is allowed to fall behind worst-case by the duration of a dashboard query and then keep up again.

This doesn't work in environments with more esoteric SAN-based replication strategies like Aurora, where max_standby_streaming_delay can't go beyond 30 seconds. In this case we have to use some combination of strategies: making CoW clones for each analytics task, architecting data to avoid leader/replication conflicts, for example by using partitioning, retrying replica queries until they don't access hot rows, or falling back to traditional analytics/data warehouse solutions at the application or logical replication layer. Not having to do these things would be a nice benefit over Aurora.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: