---
title: "The connector count is a vanity metric"
description: "Every backup vendor advertises how many integrations they have. It is the wrong number, and the moment you need the one they do not support, it is worth exactly nothing."
url: "https://saved.sh/blog/the-connector-count-is-a-vanity-metric"
date: "2026-07-22"
author: "saved.sh"
tag: "Engineering"
---

Open any backup vendor's homepage and you will find a number. Thirty
integrations. Fifty. Two hundred. It is on the page because it is easy to count
and it looks like progress.

It is a bad number, for a reason that only becomes obvious on the day it matters:
**a connector list is a list of things somebody else decided were important.**

## The arithmetic nobody does [#the-arithmetic-nobody-does]

A vendor with fifty connectors has covered fifty things. Your infrastructure
contains some number of things that need backing up, and the interesting question
is not how many of them are on the list. It is what happens to the ones that are
not.

<Stats>
  <Stat value="50" label="Connectors a competitor advertises" />

  <Stat value="1" label="Systems you run that are not on their list" />

  <Stat value="0" unit="%" label="Of the problem their number solved" />
</Stats>

That last column is the whole argument. If the thing you most need to keep is not
on the list, a longer list has not helped you. It has told you that the vendor
built for somebody else.

## What we do instead [#what-we-do-instead]

There are two ways to get bytes into a backup system. One is a connector we
wrote. The other is a command you wrote. Both land as the same artifact, under
the same encryption, with the same retention.

<Figure caption="The catalog bounds what we read for you. It does not bound what you can keep.">
  <SourceFan />
</Figure>

```bash
# a connector we shipped
sctl backup create prod-db --kind local
sctl backup configure <backup-id> --source-type postgres --worker laptop

# something we have never heard of
mystery-tool export --format binary > dump.bin
sctl backup submit <backup-id> dump.bin
```

The second line covers everything the first cannot. Not as a workaround, and not
with a reduced feature set: the artifact it produces is checksummed, encrypted,
retained under a lock and restorable by hand exactly like the other one.

<Aside title="The honest version of our own number">
  We ship eight source types and two more are in progress. That is a small number
  and we are not going to dress it up. The reason it does not constrain you is that
  the last option is "anything you can produce a file from", and that one has no
  ceiling.
</Aside>

## Why we would rather have five that hold [#why-we-would-rather-have-five-that-hold]

Every connector is a promise that a specific system's edge cases are handled: the
version differences, the flags that change output format, the failure mode where
the dump exits zero having written nothing. That work is real, and it does not
scale by writing more connectors faster.

Shipping thirty that mostly work is a worse product than shipping five that
hold, because the failure is silent and arrives a year later.

<Aside title="A question worth asking any vendor" tone="accent">
  Not "how many integrations do you have", but "what happens when I need one you do
  not have". If the answer is a feature request form, the connector count was
  describing their roadmap rather than your coverage.
</Aside>

## The number that would actually mean something [#the-number-that-would-actually-mean-something]

If we were going to put a number on the page, the useful one is not how many
sources we read. It is how many of the things you need to keep can end up in a
verified, encrypted, restorable artifact.

For us that number is all of them, and it has been since the first release,
because the answer never depended on the catalog.