You are comparing watermelon with an apple, when you look on a platform the first thing to watch is performance
1 Like
You can’t gauge performance without a lot of predicates.
Both platforms are tangelos until you set a context.
1 Like
Watermelon is an apt image for Airtable
1 Like
The first thing I try to watch for from now on is people. Performance won’t fool me again like it did with airtable. What good are tech specs if the human performance is complete chaos.
2 Likes
And even if you were skeptical of the specs and the team, Airtable has not been a bright shiny example of performance or scale. I think 25% of @ScottWorld 's massive list of functional shortfalls is related to performance or scale. The scale of these tools comes in two flavors - horizontal adoption in the enterprise (i.e., access control, synching, etc) and data throughput (i.e., max rows, automation runs, script timeouts, etc).
It doesn’t matter if they are perceived as watermelons or apples - both products have shortfalls given specific contexts (e.g., you must use predicates for any declaration of success). Sometimes the shortfall is the implementer who knew (or should have known) the technology was ill-prepared to perform. These are constraints, not necessarily failures.
So many rescue cases I’ve worked on got to crisis levels because the implementers - both internal builders and external consultants - failed to consider the question of fitness of purpose. Who should be blamed for this? The platform? Or the implementers?
The implementers sleep well at night by pointing to the specifications to unfairly place blame on the platform. This doesn’t carry any weight with me. Fixed automations is a ceiling you need to factor over time, not just day one. Blaming failure on platform specs doesn’t put finer points on the nature of performance, which is predicated on many things including, but not limited to:
- The client-side memory and compute stack.
- The performance impact of API calls used for polling.
- The lack of investment in event-based architectures.
- The flagrant use of fields as intermediate value-holders and computations.
- The lack of script profiling and optimized use of the SDKs.
- The data model itself.
- The big one - a failure to craft the solution with a deep appreciation for operational vs. strategic data management.
We’re WAY off-topic in this thread now, and I wish it were as simple as establishing these products as two types of fruits. Our comparisons of these platforms are often as poorly crafted as our pre-assessment of performance or inability to gauge fitness for specific solutions. 
My recent observation is about the nature of the two companies - one with vast resources ($1.2b and 1,000+ people) vs. one with minimal resources and a development team you can count using fingers on one hand.
SmartSuite is certainly not solving “all” of the pain points that Airtable has failed to solve. However, it’s my experience that the smaller, tighter team is more likely to do so.
5 Likes
SmartSuite being a relatively small company, means higher risk for your solution deployed on their platform if you spent 1000’s of hours to develop it. While the lean character has advantages for now, when customer base grows, so do the over-head costs. In software business there are 2 possible outcomes: a) you either grow or b) you decline. There is no 3rd way because stagnation is a decline. Competition is ripe with a low barrier of entry, you don’t need to look far for examples like Stackby eager to copy Airtable without shame. Airtable also used to be a small a nimble company. If you haven’t been around that long you may not know but it grew its headcount 8x from the end of 2019 to 2022, and was able to quickly grow from $10 million to $100 million ARR. I would give Airtable 12 months to sort out the chaos before looking seriously elsewhere. Before looking at something else, I would ask also what other innovations the other solution brings. SmartSuite is good at resolving the issues Airtable has/had, but what further innovations is SmartSuite brining other than just creating a better version of Airtable.
That’s true. There are risks with every path. Use caution. Invest with eyes wide open. Use lots of predicates when crafting requirements. Above all, communicate the risks to your clients.
I’m bringing this question around again, mainly because I’m wondering if the root database engines are playing so much a part of the reason that Airtable and others such as Monday take so long as they do to bring features and fixes to market.
I know next to nothing about such engines other than there is basically SQL and NoSQL, generally. I know FileMaker, while still using its legacy engine called DRACO, has been working on what they call “new stuff” using MongoDB. Their development seems to be going rather slow, IMO, but I could be very wrong.
In the meantime I’ve enjoyed SmartSuite the last two weeks but certain things throw me a little; sub-items and multiple items or records in what appears to be a single field. Curiously, SmartSuite HQ is within a short walk from me and also very near the previous HQs of some legacy software companies that invented and worked with DB technology decades ago which used “multi-value,” a type of NoSQL nowadays.
I’m wondering, is it currently a case of; “What was old is now new again?”
Good morning @Avi
I’ve finally decided to invest time in reviewing SmartSuite’s features - and my initial experience has been very positive!
May I ask, regarding item 5;
Dynamic choices in linked record fields is live in SmartSuite!
Will the filtering be expanded with Single and Multi-select fields? Reason I ask, is that there are many cases where this dynamic filtering is required, but the use of a Single / Multi-Select field is preferred over a Linked App - usually due to scoping. Experimenting with Dynamic choices this morning, they worked exactly how I’d hoped within a Linked Field context, but then it dawned on me how they’re also needing that same ability but with Single / Multi Select fields - and importantly, the ability to use Linked/Select fields interchangeably within that advanced filter, in that, I may need to check a Single Select field against a Multiselect field (or a Linked Record field).
On the upside - the workaround is to convert all Single / Multi Select fields into their own App tables - but by doing this, I think you start to see how by being able to dynamically reference Single / Multi Select fields directly would be an advantage.
As a side note, I love the feature request board!!! I’ve posted my suggestion here, as I searched but couldn’t find this feature already requested.
1 Like
I like to check if the solution has bit more weight before I put the eggs in it. For example I am looking for tell-tell signs of how broad is the solution accepted on 3rd party platforms and in 3rd party support forums for example here… https://hightouch.com/
There is no mention of SmartSuite there yet.
It’s certainly one indicator of adoption trends. However, it can also be a worthless signal.
Imagine a no-code platform was so good that it needed no third-party integration support. Or, that by design, it eliminated the need to use other solutions to make the primary solution functional? There would be no evidence of the platform in these integration glue factories, and you might dismiss it as a viable platform.
This is partly why disruption often takes us by surprise. It sneaks up on us because it’s unlike everything we’ve come to assume is required.
You may have noticed my occasional surveying of developers here in TableForums and elsewhere as I problem for sentiment concerning Airtable aftermarket tools. The questions typically go like this -
If Airtable was able to magically do “x” internally, would you still use Make to address this requirement?
Many respondents say - I would not want to put all my eggs in the Airtable basket, so I would continue to use Make. This is irrational, of course, and when pressed, these respondents change their views. Make and other integration adhesives exist because the core product(s) are incapable of performing what Make provides. These tools provide roads where no roads previously existed. But what if you didn’t need a road in the first place?
In my view, properly vetting a platform requires a number of data points. The absence of activity is interesting, but it may also be misleading.
No third party integrations for primary use cases? Maybe. But no support for third party integrations at all sounds like either the product hasn’t matured yet for people to come up with creative uses. Or the developers were short sighted and underestimate what consumers do.
You missed my point entirely. If there were such a product, would the lack of evidence that this hypothetical product is absent from the aftermarket platforms that service similar platforms that cannot function without them, be a good measure of success, adoption, or maturity?
The hypothesis put forth by @itoldusoandso suggests that a lack of people using glues and integration adhesives by a newcomer to the market is a data point we should use to gauge success. I’m saying this hypothesis is flawed if a new approach needs no traditional adhesives.
If you gauge interest in any new technology based on its association with a birds-of-a-feather approach, you will miss opportunities with platforms that work differently, were designed better, and are probably more innovative.
And therein, you failed to recognize one possible condition - that the new platform didn’t require anything that your perception of the current marketplace offered.
If you examine this in a micro-context with rich text fields, there exist vast numbers of Make and Zapier activities that integrate Google Docs with Airtable. With SmartDocs, no such integrations are required. Ergo, there will be far less evidence, if any, in the glue factories concerning the creation and management of very rich documents.
You’ve also conflated this:
No third party integrations for primary use cases?
With this:
No integrations for primary use cases?
What if integrations are occurring, but without third-party platforms? This is increasingly the case with the systems I build, and I suspect many are trending in this direction. A well-designed platform could come along and eliminate the need for Make. If that happens, your assessment of a tool based on third-party “presence” is flawed.
I think we are talking past each other here. I don’t think it is possible for there to be a product that is so good that people won’t want third-party integrations. I think that human nature will make people want to integrate a good product with other things.
To me, this is semantics. To me, an integration that use two different SaaS products is a third-party integration. First party = user; second party = first SaaS product. Third party = other SaaS product. An integration that uses a glue factory has multiple third-parties. An integration that doesn’t involve multiple SaaS products would be an integration that doesn’t a third party–such as having a button in one Airtable base call a webhook in a different Airtable base.
But even so, I think that humans have a huge capacity for coming up with new and unique ways of integrating things, and having integration platforms helps with situations that customers come up with that the original developers didn’t anticipate.
What if you had twenty integrations in an Airtable solution that didn’t involve a third party?
And in this case, Make might not be needed, correct? In fact, an external intermediate platform may not be required, right?
That is where I think we are using different vocabulary.
Correct. Make (or another glue factory) would not be needed. The external intermediate platform may not be needed. However, I thought we were talking about
I didn’t think that the 3rd party platform needed to be an integration platform. I thought that any SaaS product could be that 3rd party platform, so direct integrations would count.
For example, I learned about Cloudinary from the Airtable community forums. Several of those discussions didn’t involve using a third party integration system to glue Cloudinary and Airtable together. However, the volume of chatter about Cloudinary on the Airtable community helped validate the idea that Cloudinary was a platform worth looking into.
Whether ANY integration exists between Airtable and another platform or SmartSuite and another platform is not the essence of this recent thread within the thread. Rather, it’s the use of an integration medium (like hightouch…com) as a data signal for determining broad adoption, and therefore, less risk as a developer.
@itoldusoandso is correct - there is a lot of activity about Airtable at hightouch.com. There is no mention of SmartSuite. One might conclude from this that there’s no interest in SmartSuite. I’m simply saying - be careful using this approach as a data point for determining acceptance and veracity in the marketplace.
Monday.com is referenced 8,000 times at Make.com. Should I place a sizeable bet on that product?
UPDATE: I was reading and learning more about SmartSuite today and wondered, is DataShuttle a possible reason why we don’t see a lot of activity in the glue factories about SmartSuite? Perhaps @Avi could comment - would love to know the cost and if this is a SmartSuite-developed integration tool.
Smartsheet and Smartsuite are completely different products. Smartsheet has been around a while before Airtable. I liked Smarsheet for project management because it was flexible like Excel but it sucked with everything else. It’s more like a sandbox compared to Monday which is more of a consumer centric approach. Smartsheet has good reports.
So well here is more info if you need:
https://www.g2.com/compare/smartsuite-smartsuite-vs-smartsheet
Ha ha! Autocorrect sent me down that rabbit hole. Thanks for setting me straight. But DataShuttle is still interesting.