[andydb]

It's not currently possible, partly because it complicates the deployment model quite a bit. Dynamically bringing SQL pods up and down requires a technology like Kubernetes. It takes some serious operational know-how to keep it running smoothly, which is why we thought it would be perfect for a managed Cloud service.

What would be your company's reasons for wanting this available in self-hosted CRDB? What kinds of use cases would it address for you?

[nonameiguess]

It's understandly not something a lot of vendors consider, especially early stage products, but classified systems don't have Internet access and can't use managed cloud services (unless offered by AWS via C2S, and possibly in the future by whoever wins JEDI if they resurrect that), leaving no choice but to self-host anything. That's the extremest example, but lots of enterprises airgap part of their network for other reasons, and private companies that don't handle officially classified data may still be restricted in where they can host data based on PII/PHI legal regulations, and may not be able to use your data center.

[dilyevsky]

In addition to security/legal stuff there are also concerns around slo/business continuity and costs

[andydb]

Sure, those are all good points. We'll definitely keep an eye on customer demand in these areas so we can make good prioritization decisions. It can be frustrating when there are so many things that we'd like to do, but we can only pick a small subset to actually do.

[dilyevsky]

I’m actually thinking for side proj (I’m very familiar with running production crdb in k8s via my current job) - the usecase is to bring isolated “virtual” crdb cluster per customer to save on operational overdhead of managing many crdb clusters in kubernetes (which is doable but requires extra automation). That’s not how we handle customer mutitenancy at my current job but I’m sure this could be common usecase. Now I could use your cloud but I sure am interested in diy option as well