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

21–30 of 82 posts

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

#21

Post by vinarun »

teej wrote: post #17

Salesforce reps don't even know what Heroku Connect is. I couldn't get someone to sell it to me! I think the idea is great, glad to see someone picking it up.

Yeah agreed! We were surprised to hear how deeply bundled Heroku Connect is in their Enterprise plan. Reps not knowing about heroku connect coupled with their abandoned roadmap make us excited to build a better solution

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

#25

Post by kunalrgarg »

salesforcequit wrote: post #16

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…

That's awesome that you set this up, thanks for paving the way! Our users who want real-time syncs and are watchful of their REST API limits typically opt in for our streaming solution (I believe the pub/sub api was a recent addition to their change data capturing APIs). Too much polling definitely has its issues with limits as you mentioned, but we allow our users to set their own frequency to meet their needs.

If I'm understanding correctly, the scheduled jobs refer to the Bulk API (I agree it executes at seemingly random speeds). We only use the bulk api on the initial “seed”, where we write a large amount of data from salesforce to postgres. Otherwise, when it comes to reading/writing data, we stick to the REST API, which we’ve found pretty performant and which Heroku Connect seems to rely on, too: https://devcenter.heroku.com/articles/mapping-configuration-...

> Are you limited to working with customers that are paying Salesforce enough…

Yeah, right now we do require that users are on Salesforce plans that include API access, which are Performance, Developer, Unlimited, and Enterprise (or Professional w/ API add-ons).

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

#26

Post by wintogreen74 »

ianyanusko wrote: post #6
jlaneve wrote: post #5

Earlier quoted context omitted.

I don't know much about Bracket, but looking through their docs[1] it looks like they support streaming from Salesforce as an alternative to batch/scheduled jobs (which is what Fivetran does) [1] https://docs.usebracket.com/streaming

Yup! We offer two ways of interacting with Salesforce: polling and streaming. The benefits of streaming are faster syncs and optimized Salesforce API usage. Right now, we're focusing on use cases that require changes to be synced within a minute. Fivetran and its ilk are generally more focused on large data batches at less frequent intervals (e.g., to unlock 1-minute syncs at Fivetran, you must be on the Enterprise p…

We use Fivetran for big data sets but less frequent one-way syncs as you reference, and it is great but VERY expensive.

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

#28

Post by ianyanusko »

cpursley wrote: post #24

Is bracket using Postgres CDC (via WAL)?

We use a custom trigger to build an event log in Postgres. We actually found it more straightforward to use this approach than to use the WAL packages we considered.

If you're curious, you can read more about our approach to it and the actual SQL we use here: https://docs.usebracket.com/streaming#postgres

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

#29

Post by nextworddev »

Meta observation: lots of YC companies basically build their startups around some workload (e.g. salesforce db) and sell some managed service around it. This game is quite difficult to scale and sell to enterprise. But it's understandable that many technical founders are most familiar with these types of "painpoints" and thus have their startup thesis around them.
Post reply on HN