* 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?

▲

samlambert 4 days ago | parent [-]

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?

	▲	bri3d 4 days ago \| parent [-]
		> 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.