KuttiDB.GitHub ↗

PRIVACY / TELEMETRY

Small signal.
Clear limits.

Telemetry is optional, and it only ever measures community-level activity — never people, accounts, or live users. Plain server builds cannot report at all; the official opt-in build reports by default because you said yes; and the installer sends a separate count-only signal for every run.

For community adoption only.

These reports exist only to show the community a rounded picture of KuttiDB adoption. They are not diagnostics, support tooling, monitoring, account analytics, or a way to investigate a specific installation.

What leaves
your server.

Three fields

Schema version, a random installation identifier derived for this endpoint, and one bucket of open native connections: 0, 1, 2–5, 6–20, 21–100, 101–1000, or 1001+.

Keys, values, queue names, message bodies, paths, hostnames, IP addresses, usernames, and exact client counts are never part of a report.

One delayed report

An enabled server waits at least 15 minutes after startup, then sends a best-effort HTTPS report no more than once per day. Failures do not affect readiness, durability, or requests.

Connection pools and health probes are included in the sample. Embedded clients and Management API connections are not.

The installer's
count-only signal.

Every run of the official installer sends one count-only signal before anything else: exactly {"schema_version":1}. No installation identifier, no device details, no operating system, no answer to the telemetry question, no local state. It is counted whether the user answers Yes or No, and re-runs count again. DO_NOT_TRACK=1 disables it; an unreachable collector is dropped silently and the install continues.

POST https://telemetry.kuttidb.com/v1/install
content-type: application/json

{"schema_version":1}

Where the client
numbers come from.

The npm, PyPI, and crates.io figures are public registry download counts that our collector caches every six hours. They involve no KuttiDB user data and no opt-in: registries count package downloads, including CI jobs and, where the registry counts them, mirrors (PyPI figures exclude known mirrors). Maven Central publishes no download statistics, so its cell stays empty instead of guessing. Downloads are not installations, and not people.

Your control.

Telemetry support is an optional build feature. Self-built capable binaries start with reporting off and enable it with --telemetry on; the official build the installer ships after you accept the community opt-in reports by default. Either way, --telemetry off or DO_NOT_TRACK=1 disables it — then restart. DO_NOT_TRACK=1 also disables the installer's count-only signal. A custom HTTPS endpoint receives the only native report.

make TELEMETRY=1
./kuttidb --telemetry on --telemetry-state-dir /var/lib/kuttidb/.telemetry
DO_NOT_TRACK=1 ./kuttidb --telemetry on

How public
numbers work.

Rounded aggregates

The website publishes only rounded 7- and 30-day reporting-installation totals. Counts below 20 are withheld. Connection distributions are withheld unless every non-empty bucket reaches that threshold.

Limited retention

The collector retains pseudonymous report rows for 35 days, then keeps only ID-free daily aggregates for up to 13 months. Backups contain aggregates, not report identifiers.