Connect a Data Mesh destination
What you'll build
A live subscription that receives a published data stream and writes it to a destination system — a database, S3 bucket, Kafka topic, webhook, or other target. The destination connects to the Data Mesh, not to the origin's source database.
Before you begin
- An active Data Mesh origin with a Publication ID (see Set up a Data Mesh origin)
- Console access with OrgPrivileged role or higher
- Credentials for your destination system
Step 1 — Navigate to Data Mesh
In the Console, select Data Mesh → Destinations → New Destination.
The destination wizard opens.
Step 2 — Select publication
Enter or search for the Publication ID from your origin.
The Console displays the publication's schema — field names and types — so you can plan your field mapping before configuring the destination.
Click Next.
Step 3 — Choose destination type
Select the connector type for your target system.
Common options:
| Connector | Use for |
|---|---|
| PostgreSQL | Write to relational tables |
| MySQL | Write to relational tables |
| S3 | Write objects to a bucket |
| Kafka | Publish to a Kafka topic |
| HTTP Webhook | POST to an endpoint |
| Redis | Write to key-value or pub/sub |
Select your connector and click Next.
Step 4 — Configure destination connection
Enter your destination system's connection details. Fields vary by connector type.
S3 example:
| Field | What to enter |
|---|---|
| Bucket | S3 bucket name |
| Region | AWS region (e.g. us-east-1) |
| Prefix | Key prefix for objects (e.g. data/orders/) |
| Format | json (default), csv, or parquet |
| Credentials | IAM role ARN (preferred) or access key and secret |
The Console validates the connection before proceeding. Fix any errors before clicking Next.
Step 5 — Map fields (Bloblang)
The Console shows the source schema on the left and a Bloblang editor on the right.
A pass-through mapping is pre-filled:
root = this
This forwards every field from the source message unchanged. Customize the mapping to rename, filter, or transform fields before they reach your destination.
Example — rename fields and convert units:
root.order_id = this.id
root.amount = this.total_cents / 100
root.created = this.created_at.ts_unix()
Click Validate to test the mapping against a sample message from the publication. The Console shows the transformed output so you can confirm the result before saving.
Click Next when the mapping is correct.
Step 6 — Set delivery mode and review
Choose a delivery mode:
| Mode | Behavior | Use when |
|---|---|---|
| At-least-once (default) | May deliver duplicates on retry | Destination can handle or deduplicate duplicates |
| Exactly-once | No duplicates; higher overhead | Destination supports idempotent writes |
The Console shows a final summary:
- Publication ID — the origin stream you are subscribing to
- Destination type — the connector you selected
- Connection — host or bucket shown; credentials redacted
- Field mapping — the Bloblang transform you defined
- Delivery mode — at-least-once or exactly-once
Review all fields. Click Activate.
Expected output in the Console:
Destination created: orders-to-s3
Status: Provisioning...
✓ xsubscription resource created
✓ datamesh-core consumer started
Status: Active
Status changes to Active within 60 seconds.
Verify
Confirm the destination is running:
- Console → Data Mesh → Destinations → select your destination
- Check Status: Active
- Check your target system for incoming data within 60 seconds of activation
What happened under the hood
The Console created an xsubscription custom resource. datamesh-core is consuming messages from the NATS JetStream subject, applying your Bloblang transform, and writing the result to your destination. No direct connection exists between your destination system and the origin's source database — the Data Mesh acts as the intermediary.
Next: Data Mesh concepts →