Airtable vs Smartsuite

I am currently redoing one of my Softr pages, and started looking into switching from Airtable to SmartSuite as well. Didn´t really find a topic discussing pros and cons between the two platforms when integrating it to Softr.
In the long term I want to get started on Supabase, but for now I´m thinking about switching to SmartSuite instead.

So here is a few points that I would like to get peoples experience about, if anyone has experienced any pros/cons.

Record limits in SmartSuite - since you are able to link records between solutions in SmartSuite, you don´t hit the record limit quite as fast if you have your data distributed in different solutions. It might be troublesome when working mainly in the SmartSuite interface, but are there any real downside when using this approach if the main interface is Softr?

Softr features - is there anything in Softr that doesn´t work as well with SmartSuite as Airtable?

Perfomance - how do you experience the performance when getting records from Airtable vs SmartSuite?

And feel free to add any other relevant information!

Perfomance
SmartSuite doesn’t limit API requests, at least now, and it’s typically way faster than Airtable. Combining both will give you speed performance
Softr features
We don’t yet have chart support… will come soon though

2 Likes

Thanks for the information Artur.
Are you also planning on adding support for filtering with different Views as you do with Airtable?

I hope they have this on their roadmap, as it could significantly enhance performance by allowing you to load only the relevant data for the view rather than the entire table.

I currently use SmartSuite and prefer it over Airtable. However, I wish they would focus on completing the integration rather than adding more beta data sources, as the platform has been in beta for quite some time now.

Here is some feedback on the new list, list details, and calendar blocks:

  • When using Softr tags with SmartSuite, the option to wrap text does not work.
  • The option to define color as a source in Softr tags with SmartSuite does not work.
  • It would be beneficial if Softr synced live when edits are made in SmartSuite, similar to Noloco.
  • The user sync should be live and seamless like Noloco. Currently, if an email is updated for a user in SmartSuite, it creates a duplicate in Softr and also a duplicate in the SmartSuite users table.

Thanks for your feedback @Nick

Generally, views are the best option from a development standpoint, cause the conditions for a view could change, which could negatively impact your listing in your app without the developer noticing it. Also, with our conditional filtering, it happens on the server side, meaning it only loads the data required and no more, keeping the performance of this high.

Otherwise, I’ve passed your feedback onto our team! Thanks for sharing, as always!

Also, some updates re. your points above:

  1. This seems like a bug. Can you report to support?
  2. color sync will go live soon (new week ish)
  3. We’re unsure if we’re going to support this or not.
  4. this is how we approach all of our other data sources and plan on keeping it this way at the moment.

Hope this helps!

1 Like

It would be nice to at least have the option to limiting data by view, like you can with Airtable.
Even though it is pulling from the server wouldn’t it still have to filter through the entire table? Example - If my table has 50,000 records with 200 fields, but I really only need to bring in 500 records with 10 fields to Softr, wouldn’t it be quite a bit faster only fetching the view?

Thanks

Thanks for the updates.

  1. This seems like a bug. Can you report to support?
  • I have reported it 3 times (14, 15 & 17 weeks ago)
  1. color sync will go live soon (new week ish)
  • Great. Looking forward to it.
  1. We’re unsure if we’re going to support this or not.
  • For us it would be a massive step forward. We are a staffing company and we send text to our staff when new jobs are available and they can go to their portal and sign up for the job if they are interested. We use one click update “Sign up” button that assigns them to the job, then we have conditions to hide the record when it is filled. The issue is if multiple staff are in their portal at the same time and one person signs up, all the other staff still see the job as available and are able to sign up and overwrite the previous person that signed up, until each staff members page refreshes.
  1. this is how we approach all of our other data sources and plan on keeping it this way at the moment.
  • Is it because each user is tied to the email address and it creates new user when we change their email on the back end? If so, wouldn’t it be better to have the user tied to their record ID vs email?

Thanks!

Even with the view, Softr will return all of the fields with Airtable for the associated records. Airtable’s API isn’t advanced enough to return only the fields that have the data required. I know this can be done with Xano and SQL though.

What about SmartSuite?

I didn’t realize with Airtable it still pulled all fields for the records in the view. Wouldn’t it still be beneficial to fetch the only 500 records vs the 50,000?

I believe smartsuite is in the same boat - normally it’s an advanced feature to only return the fields of a record that are being used on the page.

Using conditional filters in Softr you can achieve this affect - only fetching the exact data that you need. But still, each of those rows would contain data to all of the fields on each record.

Also, we don’t use recordId rather user email help us easily change records & add/delete move between systems, which is why we’ve stuck with this approach for all data sources.

Thanks for your responses.

Using conditional filters in Softr you can achieve this affect - only fetching the exact data that you need. But still, each of those rows would contain data to all of the fields on each record.

  • Gotcha - I didn’t realize using conditional filters in Softr on 50,000 records in the entire table would be the equivalent to using the view with 500 records (preformance wise).

Also, we don’t use recordId rather user email help us easily change records & add/delete move between systems, which is why we’ve stuck with this approach for all data sources.

  • I guess I don’t understand this concept as you could still utilize the users email for all of those things between different platforms. Since 1 user is always equal to 1 record in the users table, to me it just makes sense to tie that user to the record ID which never changes (for syncing purposes).