Burrow assumes it runs the database; some clusters require RDS or a managed service

[incognick]

TL;DR

Burrow assumes it runs the database. Some clusters will not allow that at all.

• A platform team may forbid stateful workloads in the cluster outright, and require RDS, Cloud SQL or DO Managed Databases.
• That is a harder constraint than the CustomResourceDefinitions ADR-0086 introduces, because no amount of operator installation satisfies it.
• Two tiers, and they are very different in cost: point at a database you already have, versus provision one for you.
• The first is cheap and covers most of the requirement. The second is where Crossplane would earn its place, and it should not be the first step.

What I need from you

Nothing. Filed to be reasoned about before somebody asks.

---

Where Burrow stands today

Every Postgres path assumes Burrow creates and runs the server:

• Add-on instances are CloudNativePG Cluster objects in the cluster (ADR-0066).
• burrowd's own database is a plain in-cluster Deployment, and ADR-0086 proposes making it a Cluster too.
• burrow addon connect looks like the seam and is not: it registers observability backends, takes an in-cluster host:port, and authenticates with a bearer token. Nothing about it fits a managed Postgres reachable over the internet with a DSN.

So an organisation whose rule is "databases are RDS, full stop" cannot use Burrow's Postgres at all today.

Two tiers, and the gap between them is the whole decision

Tier 1 — point at a database you already have. The operator registers a connection string; Burrow provisions a database and role inside that server the way it does inside its own, attaches apps to it, and writes their DATABASE_URL. Burrow creates no infrastructure and holds no cloud credentials.

This satisfies the stateful-workload rule completely, and most of the managed-database want with it. It needs no operator, no CustomResourceDefinitions, and no cloud IAM.

What it costs: backups become the vendor's problem, so addon backup, restore and backup-health need an honest answer for a server Burrow does not run — most likely "this server is managed elsewhere; its backups are not Burrow's", which is better than implying coverage. Guardrail semantics need re-reading too: addon.remove against a server Burrow does not own must not mean what it means today.

Tier 2 — provision the managed database. Burrow creates the RDS or Cloud SQL instance, wires networking, and manages its lifecycle. Genuinely useful, and a different product surface: cloud credentials with provisioning rights, per-vendor behaviour, cost implications, and deletion semantics that can destroy data outside the cluster.

On Crossplane

Worth considering for tier 2, and not for tier 1.

Crossplane is a good fit for what tier 2 actually is — declaring cloud infrastructure as Kubernetes resources and letting a controller reconcile it. Providers for AWS, GCP, Azure and DigitalOcean already exist, so a Composition could yield an RDS instance without Burrow writing a vendor SDK integration per cloud. If Burrow ever provisions managed infrastructure across several vendors, rebuilding that is a large and unrewarding job.

But it is the wrong answer to the requirement that prompted this, and the irony is worth stating plainly: the concern is a platform team that will not accept CustomResourceDefinitions and stateful workloads — and Crossplane is more CustomResourceDefinitions, plus a cloud credential with rights to create infrastructure. It is a strictly larger ask than the one already being questioned.

Tier 1 asks for a connection string.

So: do not adopt Crossplane to solve "my databases are RDS". Revisit it if and when customers want Burrow to provision cloud resources — and note that the same argument would then apply to buckets, DNS zones and load balancers, which is exactly when a general mechanism starts paying for itself rather than being overhead.

Gaps in the control plane's own data story, for context

Filed or known, and relevant because they are what an evaluator would examine alongside this:

ADR-0086	burrowd's own database is a plain Deployment on a 1Gi volume with no backup at all — proposed fix, not accepted
#467	a new instance archives WAL for up to a day with no base backup to restore onto
#466	addon install never says whether the instance archives at all
#428	restoring a whole instance is not built, and no backup has ever been restored from
#457	reaching burrowd grants burrowd's permissions rather than the caller's

Cloud ADR-0030 is right that "a backup path we have never restored from is a claim, not a capability." Supporting an external database does not fix any of the above — it changes who is responsible for them, which for some organisations is the answer they want.

Acceptance for tier 1, if it is taken

• An operator can register an external Postgres server by connection string.
• Burrow provisions a database and role inside it, and attaches apps as it does for an in-cluster instance.
• Backup, restore and backup-health say plainly that this server is managed elsewhere, rather than reporting or implying coverage.
• Guardrails that assume Burrow owns the server are re-read, and addon.remove cannot destroy a server Burrow did not create.
• The credential is held the way every other credential is.
• burrow cluster and addon list distinguish an external server from one Burrow runs.