Licensing, Seats, and Telemetry
Free vs Paid Features
The Data Explorer, SQL Console, and connection management are always free — no account required. An account is needed to run streams; a paid subscription is needed for clean Load output and CDC beyond evaluation.
Evaluation mode
Your first stream run starts evaluation mode — no payment required. Evaluation gives you access to the full product with the following behavior:
| Resource | Evaluation behavior |
|---|---|
| Seats (devices) | 3 |
| Load output | All rows are copied; text fields outside table keys and relationships are marked after the first 50 rows per table |
| CDC runtime | 2 hours (lifetime) |
The Account page shows the Load watermark policy and a CDC runtime progress bar. When the CDC limit is reached, CDC stream operations are blocked until you upgrade. Load completes with marked evaluation output.
What happens when you upgrade
Upgrading to a paid Streams subscription produces clean Load output and removes the CDC runtime limit. Your seat limit changes to the number of seats purchased during checkout — you can increase seats at any time from the Stripe customer portal.
Seats and Devices
Subscriptions are priced per seat, where a seat corresponds to an active device bound to your account.
How Device Binding Works
- Each device is identified by a stable
X-Install-IDheader sent with API requests. - When a new device first uses a valid API key, it is bound to your account (if seats are available).
- If binding a new device would exceed your seat limit, the request is rejected until you deactivate a device or increase seats.
- Deactivated devices are rejected for stream operations until reactivated.
Managing Devices
Device (seat) management is available from the Seats & Devices section of the Account page. From there you can:
- See how many seats are used out of your limit (e.g. "1 / 3")
- View each bound device with its label, status, and last-seen timestamp
- Rename a device for easier identification
- Deactivate a device to free up a seat
- Reactivate a previously deactivated device (if seats are available)
Required API Headers
All API-key-authenticated requests require two headers:
| Header | Purpose |
|---|---|
X-API-Key | Account authorization |
X-Install-ID | Per-device identity for seat enforcement |
Telemetry
DBConvert Streams collects minimal, non-PII telemetry to improve the product and enforce licensing.
What Is Collected
| Field | Description |
|---|---|
install_id | Random per-installation identifier (not personally identifiable) |
event_type | install or runtime |
deployment_type | docker, desktop, or server |
version | Streams version |
os | Operating system (linux, darwin, windows) |
arch | CPU architecture (amd64, arm64) |
distro | Linux distribution and version when available |
When Events Are Sent
- Install event — sent once during installation. No user identity is attached (anonymous).
- Runtime event — sent on first authenticated API usage. Links the install ID to your account for seat enforcement.
Install ID
The install ID is generated automatically on first launch. Both the API key and install ID are visible on the Account page in the app.
For Docker deployments, the install ID is set via the STREAMS_INSTALL_ID environment variable.
Stream run diagnostics
Separately from the install and runtime events above, each stream run reports its outcome so that the CDC evaluation runtime policy can be applied and failures can be diagnosed.
| Field | Description |
|---|---|
| Status | FINISHED, FAILED, STOPPED, or a limit-reached status |
| Data volume | Bytes transferred during the run |
| Runtime | Active runtime in seconds |
| Source and target types | Engine kind on each side (for example mysql, postgresql), not connection details |
| Stream mode | load or cdc |
| Failure message | The error text returned by the engine when a run fails |
What the failure message contains
When a run fails, the error your database or the engine returned is sent as-is, apart from the redaction below. It names the stage and object that failed — for example Error 1406 (22001): Data too long for column 'first_name' at row 1.
That means table and column names can appear in a failure message, because they are part of the error text. Row values, query results, and table contents are not sent.
Before a failure message leaves your installation it is stripped of URLs, key=value pairs that look like credentials, email addresses, and any quoted text that is not an object name, then truncated to 500 characters. A rejected row is removed while the object it was rejected by is kept: Duplicate entry 'acme-2026' for key 'orders.PRIMARY' is sent as Duplicate entry [value] for key 'orders.PRIMARY'.
What is never collected
Your table contents, query results, connection strings, and credentials are never sent. Streams reads them only to move your data between the source and target you configured.
Reporting a failed run
A failed run has a Report to Support button. It is the only way your schema reaches us, and it never runs on its own.
Pressing it opens a dialog containing the exact text that would be sent, so you can read it before deciding. That text holds the failure message, the engines on each side, how far each table got, and the CREATE TABLE definitions of the tables the run was copying. It holds no table contents and no credentials.
Nothing is stored when you send it: the report is emailed to support, answered by a person, and lives only in that mailbox.