Hey Softr community, wanted to share how the company I work for is making Softr more valuable in case it’s helpful to others too. We are using Softr mainly for internal tools but I think this would be helpful for any use case if your company has a database.
We use Postgres to hold our data but customer service and sales wanted to build tools for their teams, and since they’re not engineers they didn’t have access to data they needed in Postgres, and felt more comfortable in Airtable (which is why they pushed for Softr).
At first we tried getting the engineering team to connect Airtable and Postgres but the syncs kept breaking. We tried working with the Airtable API and BaseQL but it wasn’t a good long term solution.
Zapier does work. But it didn’t catch deletes or certain updates. If you’re looking to send only new records and send data in one direction, I’d use Zapier.
Bracket worked really well. It sends data from Postgres to Airtable (whether it’s an update, delete, anything), and it sends data from Airtable back to Postgres. So when customer service or sales team members made updates in our Softr apps, those changes were logged in Airtable and then sent to the rest of the business (because it was sent to Postgres). I made some fields only sync one way so that they couldn’t just change any data in the database.
Bracket does work with Google Sheets and other databases (SQL & NoSQL) too but I haven’t tested the product with those. I’d imagine it works similarly though.
I tried some ETL solutions but it didn’t work well for this use case and seemed like overkill.
I use DataFetcher for a similar use case. In my case it’s fetching data from a GraphQL API instead of from another database, but conceptually it’s “get data from a foreign system into Airtable so Softr apps can use it.”
Would love to see a direct MySQL integration. We’re already having to plan on how to deal with AT limits. As we are now, we’ll have to archive every 6 to 9 months, which would not be a pleasant experience for our clients.
Thank you for the response, @artur. Fortunately I’m well under the limits right now but, depending on some pending client decisions, could see that accelerate quickly towards the Airtable (or Sheets) limits. I know there’s also a 25k limit per block, which might be an issue at some point.
I have 3 major tables, let’s call them: Users, Items, and Relationships, the latter tracks when Users add Items to their favorites. I am eventually hoping to add admin accounts which can decide which Items are added and endorsed by each Admin’s organization (basically a way of having super-user favorites). If that happens, I might need a second Relationships table.
I don’t think I can split data into multiple Airtable bases because I need to maintain the Relationships tables and ensure Users aren’t cut off from parts of the site, but I’m open to creative ideas there.
I’m not sure if there’s some sort of Softr > Airtable > X solution but I’m open to that
Obviously if there are other data sources that would help. I don’t have a tech background so I may need to obtain/hire for the knowledge to work with real databases, but any insights into the roadmap here would be huge.
I’m absolutely loving Softr and am optimistic that further advancements with Action Buttons might allow me to get rid of any Relationships tables. However, I still want to know that there’s a safety valve that will allow me to scale and continue to work with Softr. Thanks again!
Hi @kevingorne, amazing use case, and great to see your drive to get things work!
If you can share, I’m curious about few things regarding below:
Who in the customer service and sales teams expressed the need for the tools? Managers, Service agents, Sales reps? Can you share some examples on what kind of internal tools they want to build?
Let’s assume there’s a Postgres connector in Softr.
a) Is Airtable layer that is still needed? You’ve considered that services/sales teams feel comfortable in Airtable. I imagine they’d have to have direct access to postgres when building the app in Softr. Would that be ok to provide them with temporary direct access to postgres?
Would they still need to have direct access to some postgres tables for daily use once the internal tool is already built?
b) As you’ve “made some fields only sync one way so that they couldn’t just change any data in the database.” - who in your company would make the effort to keep the protections you want in postgres?
Basically I’m trying to better understand if and how would you approach the transition from Softr <-> Airtable <-> Postgres, to Softr <> Postgres. Who would be involved, and what would be your top concerns.