# Apps, connectors, and transforms (/docs/concepts/apps-connectors-and-transforms)



Apps, connectors, and transforms [#apps-connectors-and-transforms]

Apps, connectors, and transforms connect external data to RawTree in different
ways. They complement the normal insert and query interfaces. The resulting
rows remain available in tables through SQL.

These are RawTree Cloud and RawTree BYOC service features, where enabled.
They handle protocols, source connections, and payload preprocessing outside
RawTree. The database stores and queries the resulting rows.

| Concept   | Main purpose                                                              | Example                                                            |
| --------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| App       | Enable compatible ingestion or query protocols for a cluster.             | OpenTelemetry, Prometheus, or Splunk.                              |
| Connector | Run a managed process that reads an external source and delivers records. | Read Kafka topics into a table.                                    |
| Transform | Reshape a supported payload into rows during an insert.                   | Extract individual CloudWatch log events from a delivery envelope. |

Apps enable familiar protocols [#apps-enable-familiar-protocols]

An app enables a supported set of endpoints on a cluster. For example, the
OpenTelemetry app accepts traces, logs, and metrics through native protocol
endpoints. The Prometheus and Splunk apps add their supported ingestion and
query interfaces.

An app is a compatibility layer over the database. It does not replace SQL or
require a separate database for each signal. Its supported protocol features
still have limits, described in the relevant integration guide.

Apps are installed per cluster. Installation enables endpoints, but does not
start or resume the cluster. Uninstallation disables those endpoints. App
management and cluster readiness are separate concerns.

Connectors manage a source connection [#connectors-manage-a-source-connection]

A connector records how to reach an external source, what to read, and where
to write the records. A Kafka connector includes broker access, topic
selection, consumer configuration, and destination tables.

Saving a connector does not prove that it is delivering data. Its desired
configuration, runtime state, source lag, delivered records, and errors describe
different parts of its operation. Pausing requests a halt to ingestion
without redefining the destination table. Runtime state shows when the service
applies the configuration.

The connector service must be available in the environment. Source credentials,
network access, and destination permissions still determine whether delivery
can proceed. See [Connect Kafka](/docs/guides/ingest/kafka-connector).

Transforms change the row shape [#transforms-change-the-row-shape]

A transform is a built-in preprocessor for a supported source format. It can
extract several records from one JSON object and copy useful envelope fields
onto each row.

For example, an ordinary insert of a CloudWatch delivery object stores the
wrapper as one row. The CloudWatch transform emits one row for each log event.
That choice changes what a table row represents.

Transforms act before storage. They do not rewrite existing data, schedule
queries, or establish a source connection. The service supports named built-in
transforms rather than arbitrary custom transform code. They apply to JSON
body inserts, not URL imports.

Native OpenTelemetry ingestion uses the corresponding built-in transforms.
An explicit transform on a generic table insert does not require installation
of the OpenTelemetry app.

Choose the right combination [#choose-the-right-combination]

A sender that already speaks a supported protocol can use an app. A managed
external feed can use a connector. A supported delivery envelope can use a
transform. These are choices about transport and row shape, not replacements
for [access control](/docs/concepts/access-control).

Their success signals also differ. An HTTP request, a connector's saved state,
and an accepted export do not prove the same outcome. In particular,
OpenTelemetry can report partial success with rejected records.
See the [Ingestion model](/docs/concepts/ingestion-model).

[SQL workflows](/docs/concepts/sql-workflows) operate after data is available.
They run saved queries and can deliver results to sinks.

Related [#related]

* [Integrations](/docs/integrations)
* [Transforms guide](/docs/guides/transform/transforms)
* [OpenTelemetry](/docs/integrations/opentelemetry)
* [Apps API](/docs/reference/api/apps)