Live data from Hacker News

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

news.ycombinator.com

31–40 of 82 posts

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

#31

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…

I'm guessing the GP's scheduled jobs are running within Salesforce, probably Apex. I'd note that I've seen inconsistent async processing delays even in EE and UE clients. First of all, I'm pretty sure everyone is on shared infrastructure, and second, the delay is at least in part relative to the amount of recent processing.

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

#32

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.

Agreed that many technical founders build on the pain points they've experienced themselves. I'm curious your take on why the managed services approach is hard to scale?

IMO, the reason many YC companies struggle with enterprise sales is because it's generally much harder than PLG, with long sales cycles and delayed feedback loops. It was definitely a learning curve for us!

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

#34
This looks great! The UI and docs look very nice. Of course long-term reliability is what really matters in this space. I can definitely see incorporating this into client proposals.

A few things I can't immediately see from the docs: do you support subsetting a data source -- only sync records matching criteria? Do you support to/from different instances of the same connector (e.g. Salesforce to Salesforce)? Can you perform any transformations like map over the data, normalize or denormalize tables, etc?

Many clients I can think of this being most useful for would rather host it themselves, is that an option?

One critique: I can't imagine recommending this to a client without SSL support. I'd highly recommend just baking that in to every tier. It would demonstrate that you're serious about keeping your customers' data secure.

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

#35

Even if this only accomplished one-way directional sync with backup and disaster recovery capabilities, it'd probably find a 10x wider audience.

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

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

#36

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.

Agreed that many technical founders build on the pain points they've experienced themselves. I'm curious your take on why the managed services approach is hard to scale? IMO, the reason many YC companies struggle with enterprise sales is because it's generally much harder than PLG, with long sales cycles and delayed feedback loops. It was definitely a learning curve for us!

Opportunity for YC (if they don't already) to maybe even have pools of fractional VPSales and sales people who can help startups through advise or taking a role, to transition to enterprise sales.

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

#37
As a developer I love the idea. Choosing Postgres over say a GraphQL API is bold, but it makes sense. The customer can then scale up their Postgres instance as they hammer it more and more, and they might already being using this for their app, so developers can add it to their ORM. Or they could wrap this in a microservice.

I also liked the submission recently about a git client that uses SQL. I like the idea that more things can be exposed as SQL (either directly or by syncing with a RDBMS). There is a lot of good tooling around it and despite the S not meaning Standard, the dialects are close enough that it isn't a problem.

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

#38

Earlier quoted context omitted.

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…

I'm guessing the GP's scheduled jobs are running within Salesforce, probably Apex. I'd note that I've seen inconsistent async processing delays even in EE and UE clients. First of all, I'm pretty sure everyone is on shared infrastructure, and second, the delay is at least in part relative to the amount of recent processing.

Yeah, so far, we’ve found that this combination of the three APIs is a happy medium between reliability, simplicity, and API limit consciousness.

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

#39

This looks great! The UI and docs look very nice. Of course long-term reliability is what really matters in this space. I can definitely see incorporating this into client proposals. A few things I can't immediately see from the docs: do you support subsetting a data source -- only sync records matching criteria? Do you support to/from different instances of the same connector (e.g. Salesforce to Salesforce)? Can you…

Thank you!

> do you support subsetting a data source -- only sync records matching criteria?

In a one-way sync from Postgres to Salesforce, yes, you can apply filters using a SQL statement, but we’re working on adding this to the Salesforce side as well as two-way syncs. From your perspective, how would you want to set these filters? A SOQL query, or something else?

> Do you support to/from different instances of the same connector (e.g. Salesforce to Salesforce)?

Yup, our infra is data-source agnostic! But Salesforce Salesforce is not heavily tested, so there may be some funky behavior with oauth tokens if you’re trying to connect objects from two different instances during onboarding. Curious what use case you have in mind?

> Can you perform any transformations like map over the data, normalize or denormalize tables, etc?

Besides the one-way SQL filter I mention above, we try to make field mapping easy between the sources by automatically transforming when necessary (e.g., transforming a Salesforce picklist to a Postgres integer and vice versa). But we’re working on allowing users to create more detailed field-level transformations in the next few months.

Thanks for the feedback! Totally hear you on SSL, we’ll move that to every tier.

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

#40

This looks great! The UI and docs look very nice. Of course long-term reliability is what really matters in this space. I can definitely see incorporating this into client proposals. A few things I can't immediately see from the docs: do you support subsetting a data source -- only sync records matching criteria? Do you support to/from different instances of the same connector (e.g. Salesforce to Salesforce)? Can you…

Sorry, forgot to respond to one piece:

> Many clients I can think of this being most useful for would rather host it themselves, is that an option?

Right now you can self-host the associated datasets (like the Postgres event log table), but we're still working on allowing you to self-host the entire service. Stay tuned :)

Post reply on HN