This message was deleted.
# questions
b
This message was deleted.
a
Unfortunately its not real-time (15m sync) and read-only so not exactly usable
but yes, tables and individual records are accessible
w
thanks @abundant-dinner-65974 - just found the docs about it. Unusable indeed!
c
@witty-room-67787 checkout nocodb.com you may be able to use this against a postgress db
w
hehehe, I literally just bashed in their url to my browser!
cosmic
c
It will be a fair amount of work to get up and running. But it may prove to be a very good direction for you
s
I keep on trying out NocoDB every year, misses too many things compared to Airtable (last time I checked), but I’m definitely looking forward to use it in the future.
w
@sticky-night-20812 good to know.
Why would I shift to using nocoDB over airtable - purely the realtime sync issue?
think I’m missing the what the use case would be @clever-art-10420
c
Main point is you can edit the ui introducing your own stuff. So not a replacement for Airtable. It would be a replacement for everything. Typeform, Airtable and Stacker. But it will be a lot of work 😉
w
cool, will watch its journey. gut feeling is the opportunity cost of shifting to something like that is beginning the journey of building our own tool…
👍 1
a
@witty-room-67787 Definitely make your voice heard if Postgres supoprt is important to you. It’s a big big concern of mine and I know others as well. Without it there’s a natural point where you simply outgrow Airtable and have to leave Stacker too.
👍 1
w
I couldn’t agree more. I can see this potentially being the stumbling block that defines our journey with our current airtable/stacker stack.
e
Hey folks, thanks so much for sharing your thoughts. We definitely see Postgres as becoming an important data source for us in the future, though I don’t have any timelines on this yet. I’ll make sure your voices get heard across our engineering teams. simple smile
🙌 1
Hey @clever-art-10420 @abundant-dinner-65974 @witty-room-67787 @sticky-night-20812 After chatting to the team, we would actually love to hear a bit more about this request. • How close do Stacker tables get to what you need from Postgres? • What features are you missing most in Stacker tables to make it a good replacement for Postgres?
s
Postgre isn’t simply a database system, it’s an ecosystem. By using postgre, we get access to a million other things (pg_extensions, tools, etc.). Stacker Tables are a closed-system, we can’t connect other tools to it, AFAIK. With postgre, we could run migrations automatically, have different environments (staging, prod, “feature-branch”) and spawn/update them in an automated way. It’s hard to compare both, they’re really different. Strengths of Stacker Tables are, simplicity, it’s embedded within Stacker, hard to break, could lead to Stacker-specific features, scalability (no records limit). “Simple” things like reordering columns, add column description (documentation), migrate column type, duplicate a column, create views, all of this are things that we have with Airtable, and most of them are technically possible with Postgre, but aren’t possible with Stacker Tables.
a
This is pretty much right. Stacker tables are very far from a proper Postgres db. The biggest thing is any sort of API or scripting isn't possible with Stacker Tables. You can't run a query, you can't write any sort of script, you can't use it with other software (eg a data visualization tool). Postgres has a vast ecosystem and significant support that unlock a huge layer of sophistication that you just can't achieve with Stacker Tables (or even Airtable for that matter)
👍 2
Also Postgres can be self hosted.
I think the team at Stacker tends to prioritize features that someone who doesn't know how to code could use. I get that, but I think the reality is that there are a lot of developers (or people like me who know a little bit of code) who are looking at these tools to make their work way more efficient. I'd wager this is actually a pretty fast growing segment (devopers who use low code tools) and their needs revolve around marrying existing standards (Postgres, restful api, etc) with the low code software.
s
Funny that you should mention that, I have two webinars coming about explaining to devs how no-code can help them - more and more devs are interested in learning, indeed.
❤️ 1
e
Thank you so much for sharing, folks. I will share this with the team.
c
I can’t really add much to what has been said above. Ecosystem is probably the most important point. For us we often find our clients need some sort of basic crud app in support of the actual unique value prop they are wanting to test. Connecting to Postgres would mean that we could build an internal tool for CRUD functionality. While then building a bespoke app off the same database that tests the market hypothesis. I currently do not use Stacker tables and just hook up to Airtable. We also use firebase functions to extract data from Airtable into Firestore and on to Big Query and Google Looker for BI. The goal is to have all client business critical data in Firestore to maximise our long term data sovereignty. IMO stacker is always going to struggle to sell “host your critical business data on stacker” to any scaling business that has a CTO that understands the importance of Data and owning and controlling your own DB. Therefor Stacker should pivot and pitch that its not the data “host” but the data “interface”.
👍 1
My 2 cents on what I’d do with the company
#ideasarecheap
PS Luke was a client of ours. He would be a really really good example of a business that is coming up to a point where it makes a lot of sense to to move away from Airtable and Stacker. But the point is it doesn’t have to be Airtable AND Stacker. It could just be Airtable if Stacker supported SQL database connections, why because moving away from Airtable will likely be to SQL. In other words atm when businesses outgrow Airtable they also outgrow Stacker. What you want is for Stacker to still have a strong value prop as the business scales.
👍 1
w
+1 for points made regarding ecosystem and CRUD api. Stacker tables vs a self-hosted SQL db seems like comparing apples and pears currently. Stacker tables regularly has me questioning my exclusive use of airtable as backend, but everytime I hit the restrictions of not being able to manipulate the data in the ways I can with airtable (CRUD api, automations, scripting etc). Like @clever-art-10420 says, our small business, and my personal role in the business is probably representative of a portion of your market that exists at the edges of what Stacker is currently catering for - many will be making plans to outgrow Stacker when they reach our position, and largely because we are outgrowing airtable, not Stacker. Hence an opportunity exists for you guys to decouple from airtable, which Stacker tables is not currently achieving in any way. I'm a burgeoning dev, pawing at all the exciting options for growing our product. 3 years ago I was manually transferring data gathered from Typeform into PDF documents. @clever-art-10420's introduction of airtable into our business defined an opportunity for centralising and manipulating the data we were gathering. Then Stacker has again redefined an opportunity for us to shape this data into a front end, which in turn we have built a product upon. Stacker and Airtable have been mission critical for us - what started off as a streamlining of process has grown into the development of a tech product. But as our client list grows, so does the size of the data we are responsible for - @clever-art-10420’s last point 'atm when businesses outgrow Airtable they also outgrow Stacker' is 100% what's happening to us right now. If I had the option to continue to use Stacker as our product scales (i.e. postgres) Stacker would remain relevant to our journey. But currently this is not the case.
🙇 1
👍 2
c
Just re-read the thread and reasised I just paraphrased what @abundant-dinner-65974 had already said 🧐🎉
Without it there’s a natural point where you simply outgrow Airtable and have to leave Stacker too.
w
I think I probably paraphrased @abundant-dinner-65974 AND @clever-art-10420. I’m not apologising though 😆❤️
you can’t do too much paraphrasing when the nature of the concepts you work with are so relentlessly abstract
😅 2