Ampersand vs ETL

ETL tools, including reverse ETL, are designed to move your own data into and out of your data warehouse. This is a different use case than Ampersand. Ampersand is integration infrastructure for enterprise products, allowing each of your customers to connect their system of record to your product so agents can read and write to that data.

ETL and reverse ETL providers

Fivetran, Airbyte, Matillion, Hightouch, and Polytomic are some of the ETL and reverse ETL providers data teams use. This page broadly compares the ETL approach with Ampersand’s integration infrastructure approach. Features and capabilities will vary from vendor to vendor.

  • Fivetran
  • Airbyte
  • Matillion
  • Hightouch
  • Polytomic

Why ETL doesn’t work for product integrations

On the surface, ETL and integration infrastructure can look similar. It’s all data movement, right? Not quite. ETL tools, like Fivetran and Airbyte, are built to move your own data for the primary purpose of analytics and reporting. They assume a single-tenant environment.

Ampersand is built for product integrations, assuming that every one of your end customers will need to configure a customized connection between your product and their system of record.

In some cases, ETL can be used to hack together a product integration, but this approach creates some problems.

01 ETL isn’t built to handle your customers’ data

ETL tools started as tooling for your data team. They’re designed on the assumption that a company is moving its own data from source systems like HubSpot and Salesforce to the data warehouse. Some ETL tools now let your customers connect their own accounts, but the data still lands in a warehouse.

Ampersand is built for integrations that live inside your product. Your customers connect their own Salesforce, HubSpot, or NetSuite through an embeddable UI, choose what to sync, and map their own objects and fields to your data model.

Where the difference shows up

  • Multi-tenant setup. ETL is great for connecting to your own Salesforce instance, but product integrations need to connect to hundreds of your customers’ Salesforce instances, each with their own custom fields and objects.
  • Authentication. ETL tools are built on the assumption that you own the data; this creates permissioning headaches.
  • Systems of record aren’t one API. A product integration with Salesforce often needs change events, custom objects, and write access. ETL tools will only cover a bulk export of each table.
Chris Lu

When Fullcast built its AI-native revenue intelligence product, the team needed integration infrastructure built into the product, rather than a warehouse-centered data pipeline: ongoing reads from each customer’s Salesforce, their custom objects and fields, and room for agents to write insights back.

“We needed integrations built for our product, with control over the data model. Ampersand’s configuration-driven approach enables us to define the schema ourselves.”
Chris Lu, Head of Platform Architecture at Fullcast Read the case study →

02 ETL is built for data movement vs. data action

ETL moves data from a source system into the warehouse. Sending data back into a system of record is a separate job, usually handled by a reverse ETL tool that syncs from the warehouse. For product integrations, bi-directional actions that sync to and from systems of record will always be a requirement.

With Ampersand, bi-directional actions are a key part of the integration infrastructure. An integration can read, write, and subscribe to changes as they happen. This allows agents to take action with near real-time context and then update the system of record once that action is completed.

Where the difference shows up

  • You’re building for agent workflows. Product and engineering leaders building agentic products for customers need integrations that provide the agent with context and access. ETL and reverse ETL tools are simply not built for this use case.

03 ETL is priced on data volume vs product usage

ETL tools price by data volume: rows, records, or gigabytes synced. This pricing model is aligned with the analytics use case.

Ampersand’s pricing is built around how your product uses its integrations, not how much data sits in your customers’ systems.

Where the difference shows up

  • Large enterprise customers. Under volume-based pricing, historical backfills on a system of record like Salesforce or HubSpot get expensive for your largest customers, who have the most data.

Core differences between ETL tools and integration infrastructure

Dimension ETL Tool Ampersand
Built For Data teams loading a warehouse for analytics Product teams building customer-facing integrations
Whose Data Your company’s own systems Your customers’ systems of record
Who Connects Your team configures each source Each customer connects and maps their own system in an embeddable UI
Direction Source to warehouse; reverse ETL syncs back out Read, write, subscribe, search, and proxy through one integration
Freshness Scheduled batch syncs Scheduled reads plus subscribe actions built on provider webhooks and change data capture
Custom Objects & Fields Synced as columns; modeled in the warehouse Mapped per customer to your schema, with schema-change alerts
Destinations A warehouse, lake, or bucket A webhook into your product, a queue, S3, or your warehouse (Snowflake, BigQuery, Redshift, ClickHouse)
Pricing Usually by rows, records, or data volume Based on product usage, not data volume (see pricing)
Configuration Dashboard or API per pipeline Declarative amp.yaml in your Git repo

Why engineering leaders choose Ampersand for product integrations

  • Systems of record require domain expertise

    Your data team’s ETL pipeline connects to one Salesforce instance: yours. Product integrations connect to hundreds, each with its own custom objects, fields, permissions, and workflows. Handling that takes deep domain expertise most engineering teams don’t have in-house. With Ampersand, your engineering team can ship deep, bi-directional integrations that work across every customer’s unique configuration.

  • Integration maintenance eats into time building the core product

    Writing the initial API call takes an afternoon. Keeping track of rate limits, API changes, and schema drift across hundreds of customer accounts takes a dedicated team, and it’s a different job from maintaining your data pipelines. Ampersand significantly reduces the integration burden on your engineers.

  • Integrations should be managed as code

    Product integrations ship with your product. Ampersand integrations live in your Git repo, so your engineers review, version, and deploy them the same way they do the rest of your app.

Where ETL and Ampersand fit

ETL: your data team

  • Your data team will use an ETL tool to extract data from external source systems and load it into a data warehouse for reporting and analytics. They may also use reverse ETL to push that data back out of the warehouse and into targeted destinations. In all cases, ETL will be used on your own data.

Ampersand: your product team

  • Your product team will use integration infrastructure to build customer-facing integrations. Ampersand connects your product to your customers’ CRMs and ERPs so enterprise software and agents can read and write between systems of record.

Frequently Asked Questions about ETL tools vs Ampersand

  • Is Ampersand an ETL tool?

    No. ETL tools move your company’s own data into your warehouse for analytics. Ampersand is integration infrastructure for customer-facing integrations: each of your customers connects their own system of record, and your product reads, writes, subscribes to changes, and searches through one integration. Ampersand can deliver data to a warehouse on a schedule, which can look like ETL, but it doesn’t replace your ETL tool for analytics.

  • Can Ampersand deliver data to my warehouse?

    Yes. Ampersand can deliver to Snowflake, BigQuery, Redshift, ClickHouse, and S3, to queues such as Amazon Kinesis, SQS, and Google Cloud Pub/Sub, or to a webhook in your product. You choose the schedule and how much history to backfill when a customer connects.

  • How does pricing work if we sync a lot of data?

    Pricing is based on product usage, not data volume. So a large customer’s CRM won’t explode your bill. See pricing.

  • Can Ampersand write data back to my customers’ systems?

    Yes. The same integration that reads data can write it back, mapped to each customer’s own fields, including custom ones. There’s no separate reverse ETL pipeline. For anything reads and writes don’t cover, proxy actions give you authenticated access to the provider’s full API.

  • Should we sync a copy of the data or query it live?

    It depends on the questions your product asks. If your agents run broad or aggregate queries, like totals across a quarter, backfill once and keep a copy up to date with subscribe actions; it also keeps you clear of the provider’s rate limits. If they look up specific records, query live with search or proxy actions. Many teams do both.

Building integrations into your product?

Keep your ETL pipeline for analytics. Ampersand handles the customer-facing side: each customer connects their own system, and your product reads and writes their data. It can deliver to the same warehouse your data team already uses.