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

61–70 of 82 posts

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

#61

Post by don-code »

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…

I'l also give a shout-out to Airbyte (https://airbyte.com/), with which I've had some limited success with integrating Salesforce to a local database. The particular pull for Airbyte is that we can self-host the open source version, rather than pay Fivetran a significant sum to do this for us.

It's an immature tool, so I don't yet know that I can claim we've spent _less_ than Fivetran on the additional engineering and ops time, but it feels like it has potential to do so once stabilized.

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

#62

Post by ianyanusko »

_bry-guy wrote: post #60

I'm currently on a team tasked with thinning out our Salesforce App Exchange app. Bracket looks very cool. 1. Do you have any plans to release an API rather than utilizing a webapp for defining the sync? 2. Does your Salesforce integration support syncing metadata, including custom metadata? 3. Do you have data on the impact Bracket has on platform events and other Salesforce limits? 4. Can you share any information…

1. Yes, on our roadmap for Q1! Getting that request a lot 2. We don't currently sync metadata 3. Our footprint on your Salesforce API depends on whether you're using polling or streaming, and then it depends on the cadence of your syncs or frequency of changes. You can see some data on best/worst case scenarios here: https://docs.usebracket.com/connecting/salesforce_api 4. Yup, we priced based on the amount of data kept in sync. You can see more here: https://www.usebracket.com/pricing

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

#63

Post by motrm »

This is very cool! I built a similar tool for a project with the need for two-way data syncing between Salesforce and MySQL via Laravel.

Salesforce objects map quite nicely onto Laravel’s Eloquent models (and booleans work fine! ref @ianyanusko in a sibling thread)

On the Salesforce side we use triggers to send a summary of field changes to Laravel to apply to its MySQL database. These are very cheap in terms of Salesforce limits and consumption!

Changes originating from the Laravel side use Salesforce’s REST API. It’s handy taking the round trip through Salesforce when saving changes as it lets flows/processes run and formulas to do their thing before data is persisted in MySQL.

Syncing data from Salesforce (to seed a database for example) is done via REST too. It works OK.

I considered productising it at one point, but ideas are a dime a dozen, it’s a lot harder to execute well and Bracket is doing exactly that, kudos!

This has been a thoroughly interesting post, and I’ll keep my eye on Bracket. You are however out of budget for my client, we had to achieve syncing on a shoestring ;)

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

#65

Post by atraac »

We've built similar thing to sync certain Salesforce objects to our .NET backend but Salesforce has their streaming all built around CometD which uses something I believe an insane person came up with - Bayeux Protocol. It's essentially an HTTP streaming, you shoot a GET call to an API and it starts streaming bytes of data. If it stops or timeouts, you're supposed to shoot another GET to continue streaming bytes, if nothing comes back you timeout and retry.

It's an absolute hell, most community frameworks barely work, there's zero good solutions to error handling, we had our Azure Application Insights constantly red because of timed-out requests that are in fact good, because they just mean there were no events to transmit.

I refuse to believe that multi-billion dollar company that is Salesforce couldn't come up with a RabbitMQ sink or virtually any better solution to that problem, especially that they could gate it behind a subscription most companies would pay for since they spend millions on SF either way...

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

#66

Post by robertlagrant »

atraac wrote: post #65

We've built similar thing to sync certain Salesforce objects to our .NET backend but Salesforce has their streaming all built around CometD which uses something I believe an insane person came up with - Bayeux Protocol. It's essentially an HTTP streaming, you shoot a GET call to an API and it starts streaming bytes of data. If it stops or timeouts, you're supposed to shoot another GET to continue streaming bytes, if…

From memory, one reasonably good solution I saw was with a company called Validic that did IoT integration stuff for medical devices. They got you to set up an HTTP SSE stream, that you just connected to and consumed from as and when events came through.

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

#68

Post by no_wizard »

vinarun wrote: post #21
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

I know this is a late comment, but I have to ask, what do you think the market opportunity is on this?

500 million? Billion? Billion plus?

I'm curious how big a business like this can grow, by estimation, based on someone else's platform like this.

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

#69

Post by ianyanusko »

motrm wrote: post #63

This is very cool! I built a similar tool for a project with the need for two-way data syncing between Salesforce and MySQL via Laravel. Salesforce objects map quite nicely onto Laravel’s Eloquent models (and booleans work fine! ref @ianyanusko in a sibling thread) On the Salesforce side we use triggers to send a summary of field changes to Laravel to apply to its MySQL database. These are very cheap in terms of Sale…

Nice! Great point about the round trip - we do something similar for formulas and auto-generated fields like `Id`. That's awesome you built this in-house.

> Syncing data from Salesforce (to seed a database for example) is done via REST too. It works OK.

Have you thought about using the Bulk API for seeding? We started relying on that instead of REST, which helped us seed massive DBs much faster / more efficiently.

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

#70

Post by ianyanusko »

matchagaucho wrote: post #55
ianyanusko wrote: post #35

Earlier quoted context omitted.

Thanks for the comment - are you saying that one-way sync has a 10x wider audience than two-way syncs?

Without knowing the target market, I'm thinking the taxonomy of "two-way sync" is understood by a very narrow community. ISVs have been using this approach for years. So maybe that's the audience? If so, then Heroku connect probably does need an alternative. A business user (non-technical 10x audience) just wants to sleep at night knowing their daily backup was successful and they have recovery capabilities on-demand…

Gotcha, that makes sense. From our perspective, the one-way sync market (backups and ETL/rETL) was already saturated with heavily-capitalized players who were hitting each other hard with marketing dollars. We didn't feel that we had a unique insight with one-way syncs, but did feel like we'd come across something unique with two-way use cases.

So we decided to double down in this smaller, underserved area for now as we try to build something people love, even if it's a bit niche.

That being said, there probably is room in the backup space for challengers against the incumbents - it's a massive market.

Post reply on HN