Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 82 posts

Re: Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

#11

Post by kdazzle »

ianyanusko wrote: post #4
foobarbaz333 wrote: post #2

Doesn't fivetran/hightouch do this?

Fivetran and Hightouch do ELT and reverse ETL, respectively, which are one-way syncs. While Bracket can handle one-way syncs, two-way syncs (in situations where you need writes from both Postgres and Salesforce to sync) are our bread and butter. We’ve worked with some folks who were cobbling together ELT and rETL to achieve a type of two-way sync, but they faced three problems with this approach: most importantly, ha…

Nice. The two-way syncs are where all the complexity lies, and why people end up paying the big bucks to like Mulesoft.

Re: Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

#12

Post by kunalrgarg »

hhthrowaway1230 wrote: post #8

Nice i can see the need for this. > With the polling method, Bracket stores an encrypted copy of your data as an intermediate source of truth. We mostly do this to prevent infinite event loops, but it also helps with merge conflict resolution. I see you have an on-prem version, but i am still not convinced why you need to store it? Can it not just be stored in an extra table at the client's side?

Yes, you’re correct on that! Sorry for the lack of clarity on the docs. The snapshots would be stored in a client side table in these cases. These snapshot tables/collections can either be stored in your own PG or MongoDB.

Re: Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

#13

Post by ianyanusko »

kdazzle wrote: post #11
ianyanusko wrote: post #4

Earlier quoted context omitted.

Fivetran and Hightouch do ELT and reverse ETL, respectively, which are one-way syncs. While Bracket can handle one-way syncs, two-way syncs (in situations where you need writes from both Postgres and Salesforce to sync) are our bread and butter. We’ve worked with some folks who were cobbling together ELT and rETL to achieve a type of two-way sync, but they faced three problems with this approach: most importantly, ha…

Nice. The two-way syncs are where all the complexity lies, and why people end up paying the big bucks to like Mulesoft.

For sure, definitely has not been an easy problem to solve. The two-way syncing is one tough element (for the reasons mentioned above), and configuring our requests to the Salesforce API in a way that minimizes our footprint (while still keeping syncs fast) has been another tricky task.

Re: Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

#15

Post by ianyanusko »

isuckatcoding wrote: post #14

Love the focus. How did you find the people to talk to?

Thanks! We've had to internalize the lesson "startups can do one thing well at a time" :)

At first, it was a matter of doing discovery with people who we thought would find Bracket useful. These weren't sales convos, but pure feedback/discovery. From that process, we got a good sense of which roles face these pain points, and exactly what those pain points are.

Since then we've split our time between 1) writing content/distributing it in places people would find it helpful and 2) reaching out directly to people who would use Bracket. In the latter case, we really don't like generic sales campaigns, so we spend a good bit of time crafting each message.

Re: Launch HN: Bracket (YC W22) – Two-Way Sync Between Salesforce and Postgres

#16

Post by salesforcequit »

I tried to build this a few years ago using Salesforce’s webhooks and discovered that low-value tenants are on shared infrastructure where things like scheduled jobs can run instantly… or 10 minutes later, and Salesforce make no guarantees about when things will happen — making any attempt to use Salesforce as a source of truth unreliable.

The polling solution is neat but I am imagining it’ll run into issues with API limits and performance, especially for tenants on shared infrastructure: have you encountered that? Are you limited to working with customers that are paying Salesforce enough to have fast/reliable infrastructure?

(I don’t think it’s a problem for your success as your product is most valuable to those paying Salesforce for reliability, I’m just curious how you are thinking about the problems I gave up on! Maybe things with Salesforce have changed in the last 5 years.)

Post reply on HN