Really, really love that it's just SQL. How is data mapped to the target API from the SQL projection? Are the columns themselves the actual API contract?
Cofounder here! Not quite. In Hightouch, you define your model (SQL) and create a sync (point-and-click or JSON/YAML).
The syncs are declarative, not imperative. They don't map 1:1 to API calls by design. You tell us what you want the destination to look like, and we figure out how :). Kinda like how a database creates the best plan for your SQL query before executing it.
Here's an example - https://i.imgur.com/05T5iKK.png. This sync maps your users table to Salesforce "Contacts" and the mapping interface also encodes the foreign key relationship between Contact:Account in Salesforce. Under the hood, we do all the lookups, caching, batch API calls using the bulk API, automatically handle rate limits, and only send changes from your database.
This is one of our key design differences compared to iPaaS tools like Tray, Zapier, Workato, Mulesoft, etc., which tend to just map actions to API calls 1:1. Data integration being declarative is something I'm really passionate about personally... wrote a blog with more examples at https://hightouch.io/blog/the-future-of-data-integration-wha...
> You tell us what you want the destination to look like
Implicit mapping between SQL to target is great, but how does the SQL author know what SQL to write in the first place?
I've done no shortage of integrations like this, and there is no avoiding reading the target SaaS documentation to know what their schema looks like so I can shape data accordingly. Without that step, I can't even start writing SQL.
Not implicit but - declarative! Our goal is to provide enough context in our docs, app (e.g. autocomplete, automatic schema discovery, etc.), and resources to guide users through this and then recipes on top for common workflows!
We do a lot of validation upfront (at both the schema & data layer), and I think it's still early days there... this is a big opportunity IMO. Great callout.
We find people start with a simple SQL model + sync and then bounce back and forth and edit their queries as they explore our columns.
By syncing data to a particular field in Salesforce, you're effectively saying that the source of truth for that field is the warehouse, and not Salesforce. If you expect a human to update a field, then Salesforce is the source of truth for that field, and Hightouch shouldn't write to it!
What we typically see is that Salesforce contains data that's expected to be updated and maintained in the tool, and then other "read-only" fields coming from Hightouch.
The syncs are declarative, not imperative. They don't map 1:1 to API calls by design. You tell us what you want the destination to look like, and we figure out how :). Kinda like how a database creates the best plan for your SQL query before executing it.
Here's an example - https://i.imgur.com/05T5iKK.png. This sync maps your users table to Salesforce "Contacts" and the mapping interface also encodes the foreign key relationship between Contact:Account in Salesforce. Under the hood, we do all the lookups, caching, batch API calls using the bulk API, automatically handle rate limits, and only send changes from your database.
This is one of our key design differences compared to iPaaS tools like Tray, Zapier, Workato, Mulesoft, etc., which tend to just map actions to API calls 1:1. Data integration being declarative is something I'm really passionate about personally... wrote a blog with more examples at https://hightouch.io/blog/the-future-of-data-integration-wha...