Stitch Data: Cloud ETL Service Setup & Integration Guide

Stitch Data is a simple, affordable managed cloud ELT service built on the open Singer protocol. Connect 130+ sources to your data warehouse in minutes — no code required — with flexible replication methods including log-based CDC.

What is Stitch Data?

Stitch Data (acquired by Talend in 2018, now part of the Qlik portfolio) is a cloud-hosted ELT service that extracts data from databases and SaaS applications and loads it into your data warehouse. It is designed for simplicity — a data analyst without engineering experience can configure a new integration in under ten minutes. Stitch supports 130+ sources including MySQL, Postgres, MongoDB, Salesforce, HubSpot, Stripe, Zendesk, Facebook Ads, and Google Analytics.

Stitch is built on the open Singer protocol — an open-source standard for data extraction scripts (taps) and loading scripts (targets). This means you can run any community Singer tap locally, inspect exactly what data is being extracted, and contribute new taps to the ecosystem. Stitch adds a managed layer on top: hosting, scheduling, monitoring, and a UI. Pricing is row-based, making it more affordable than Fivetran for moderate data volumes.

Managing Sources via Stitch Connect API

# Stitch Connect API — manage sources and destinations
# pip install requests

import requests

STITCH_TOKEN = "your_stitch_api_token"
BASE_URL = "https://api.stitchdata.com/v4"
HEADERS = {
    "Authorization": f"Bearer {STITCH_TOKEN}",
    "Content-Type": "application/json",
}

# 1. List all sources (integrations)
sources = requests.get(f"{BASE_URL}/sources", headers=HEADERS).json()
for s in sources:
    print(f"Source: {s['display_name']} | Status: {s['current_step_type']}")

# 2. Create a new MySQL source
new_source = requests.post(
    f"{BASE_URL}/sources",
    headers=HEADERS,
    json={
        "type": "platform.mysql",
        "display_name": "Production MySQL",
        "properties": {
            "host": "db.example.com",
            "port": "3306",
            "database": "production",
            "username": "stitch_reader",
            "password": "secure_password",
            "ssl": "true",
        },
    },
).json()
source_id = new_source["id"]
print(f"Created source ID: {source_id}")

# 3. Trigger a manual extraction run
requests.post(
    f"{BASE_URL}/sources/{source_id}/sync",
    headers=HEADERS,
)
print("Manual sync triggered")

Singer Protocol — Taps & Targets

# Singer Protocol — tap (source) + target (destination)
# pip install singer-tools tap-mysql target-snowflake

# 1. Configure the tap (source)
# tap_config.json
{
  "host": "db.example.com",
  "port": 3306,
  "user": "stitch",
  "password": "secret",
  "database": "production"
}

# 2. Discover schema (generates catalog.json)
# tap-mysql --config tap_config.json --discover > catalog.json

# 3. Select streams to sync in catalog.json:
# Set "selected": true on each stream you want

# 4. Run the tap and pipe to the target
# tap-mysql --config tap_config.json --catalog catalog.json \
#   | target-snowflake --config target_config.json

# target_config.json
{
  "account": "myaccount.us-east-1",
  "username": "stitch_loader",
  "password": "secret",
  "database": "ANALYTICS",
  "warehouse": "LOADING_WH",
  "schema": "stitch_mysql"
}

# Singer message format (NDJSON):
# {"type": "SCHEMA", "stream": "orders", "schema": {...}, "key_properties": ["id"]}
# {"type": "RECORD", "stream": "orders", "record": {"id": 1, "amount": 99.99}}
# {"type": "STATE",  "value": {"bookmarks": {"orders": {"id": 1000}}}}

Replication Methods Explained

# Replication methods — how Stitch detects changed rows

# 1. FULL TABLE — re-sync entire table every run
# Use when: small tables, no updated_at column, source doesn't support CDC
# Pros: simple, always accurate
# Cons: expensive for large tables, slow

# 2. KEY-BASED INCREMENTAL — query rows WHERE updated_at > last_bookmark
# Use when: table has a reliable updated_at or auto-increment id column
# Pros: efficient, low source load
# Cons: misses hard deletes; requires monotonically updating replication key

# Configure in Stitch UI per-table:
# Table Settings > Replication Method > Key-based Incremental
# Replication Key: updated_at

# 3. LOG-BASED (CDC) — read database transaction log
# Supported sources: MySQL (binlog), Postgres (WAL), MongoDB (oplog), SQL Server
# Use when: you need near-real-time sync and want to capture DELETEs
# Setup for Postgres:
# wal_level = logical
# max_replication_slots = 5
# max_wal_senders = 5
# CREATE PUBLICATION stitch_pub FOR ALL TABLES;

# Comparison summary:
# Method          | Captures deletes | Source load | Complexity
# Full Table      | Yes (via full re-sync) | High | Low
# Key-based       | No               | Low         | Low
# Log-based (CDC) | Yes              | Very Low    | Medium

Stitch vs Fivetran vs Airbyte