What does the dedicated product look like, as in what will I actually receive? Are we talking about a Terraform module or something else?

Dedicated gives you SpiceDB clusters on dedicated hardware in your cloud. The clusters are fully managed by Authzed, but unlike the hosted authzed.com solution you get dedicated hardware and a direct connection to them (i.e. you don't have to go over public internet at all) and we can spin up regional clusters close to your workloads. We just (yesterday!) revamped the pricing page with more info on the different options if you haven't seen it: https://authzed.com/pricing

So I wouldn't need to deploy anything? We just buy the Dedicated option and you'll give us a URL of the cluster you spun up in our VPC, is that how it works?

that's right!

Got it, that makes sense. How does the Dedicated host handle scaling when a large number of requests come in?

Dedicated is provisioned to handle a maximum number of requests (per second), so you'd size it to your expected needs; we then have metrics that can report when you're getting close to these limits

If it turns out our size is not enough to handle a burst of volume, what should I expect to happen? e.g. if we start a big ingest and we're attempting to write more relationships than allowed/possible, will they get queued up or lost?

well, for ingestion, you'd likely have to batch anyway, so you'd want to limit the number of concurrent requests you make (but that's specific to writing)

When we get an alert, what does the process look like? We send you a message and you provision a more powerful instance? What kind of timeframe would we be looking at?

our SRE team would likely get an alert first, and notify you, but yes, you'd ask to provision more resources and we would kick off the process to do so

Got it. On a slightly different note, we've got a Prod and Test environment. Is it possible for Dedicated to expose two endpoints?

yep

Great thanks. To quickly come back to the scaling aspect: there is no automatic scaling in/out, correct? I imagine that most of the time we'll be below our expected requests but I can definitely imagine a couple of patterns in our usage where we'll see big sudden spikes with many users logging in at once.

currently, no, although I imagine we'll be looking into adding it down the roadmap

Does this provisioning affect the billing in any way? I was under the impression it's a set cost/year

yes, its billed based on the size and cluster count

I don't have the exact numbers in front of me, how much was the on-premise for both 600req/s and 1200req/s? Feel free to DM as well

DMed

How do others handle the test environment requirement? I'm leaning towards SpiceDB Dedicated but we want to copy the data from Prod to Test every week. I expect us to have many millions of nodes and relationships, this sounds like it would affect us quite a bit. Both in terms of the time it takes to copy the data as well as the impact it will have on the throughput we support while we're copying.

I don't know if you saw it yet, but I responded to your email yesterday

I did see that but it suggests to either 1) read all the data and write it back (which sounds like it would be a prohibitive amount), or 2) use the Watch API but that's only accessible for on-premise

We can turn it on for dedicated

The Watch API would allow us to bring changes in Prod to Test but it wouldn't allow us to undo the changes that were made in Test. Eventually our Test environment then deviates significantly from Prod. How would you suggest we solve that?

What is your timeline on going to prod? right now our backups and restores are admin-managed, but eventually we will expose them to end users as something you can manage through the UI (and potentially an API). Then you could just take a backup of prod and restore it to a new permissions system to use in test. Would that work?

Restoring a backup would be ideal, that's how we handle our DocumentDB resources as well. Timeline depends on who you ask.. We have a soft launch end of September and a go-live for April. What kind of timeline do you have in mind before the backup approach might be available?

September is unlikely, but we could probably have it shortly thereafter. If you want to set up a call we can talk about all of these kinds of details as well as answer any other questions you might have.

That's good enough for my internal RFC right now -- I'll see what others say and if there are no particular objections, I'll set something up to discuss specifics of these timelines