Devs who use Airtable and Google Sheets as a Database, why?

I do coding in all sorts of SQL and NoSQL databases, but often if I am creating a small database that will be used in my company (e.g. a mini asset register or catalog of books in our company library), I will jump into Coda to create it. Why? Well, here are my reasons:

• While I can easily whip something up in my favourite database, I then have to spend time creating the front end screens and fiddle around with a Ruby framework and javascript etc. All that takes time that I would far rather spend on my consumer facing stuff.
• I don't want to spend time on user authentication etc. for my team and try to link permissions to certain databases etc. All my team is in our Google G-Suite account, and Code integrated nicely with Google Auth, so giving secure access to a team member is as easy as sending an email invite and I don't have to worry about it.
• I also don't want to be worrying about provisioning yet another virtual server in our stack to manage yet another mini Ruby/Java/PHP applet that I will have to remember to update or configure or harden.

Basically, I weigh up every little 'programming' task I have to do on internal db versus customer facing stuff and I will take as many shortcuts as possible to still have a useful internal db system yet leave time to work on the nuts and bolts of the db that actually earns me revenue.

I've worked for a company that needed to create a bunch of country-specific and one-off web forms. One of the main requirements was that people from the financial sector of the company needed to be able to tweak and generate the forms themselves.
We created a bunch of relatively complex form components that would receive parameters coming from the Airtable views and multiple other places and adjust their behavior, look, and represented data accordingly. Additionally, we added layers for versioning, schema validation, and form rules parsing(dependencies between inputs and their validation).
The only reason this was done in Airtable was that it needed constant tweaking from the people used to similar tools. It was a pain in the neck for developers to build, and the process was still quite fragile in the end. Because people working with the tables never really understood that there are limitations to logic that can be implemented through table fields that are not completely constrained and understandable to non-dev people. In the end, it did the job, but it required many back and forth calls between the teams when someone new tried to achieve something not supported by our parsing/implementation logic. Mostly because people are getting used to products like Google search where you can type in whatever you want and it'll somehow figure out what you're after(I blame the expectations, not the people — it was loose specification problem). Versioning and figuring out who and what broke the process was the biggest issue with Airtable.

I've used Google Sheets as a data source in the past but it's mainly been as a form of manual approval for a process that I'm not ready to fully automate. I would go so far with the automation process, save details to a Google Sheet and then later update a status column in the Google Sheet which would allow the rest of the automation to progress.

I found this more useful than a traditional database because I could access the Google Sheet and do the review process from any computer (or my phone on the train from time to time) instead of having to always have my dev machine with database access to hand.

Really interested in that too. As a developer it's actually easier for me to store data in some kind of NoSQL db.
Maybe for someone without technical background it's just easier to use what they already know?

Anyway, I'll wait for other replies :D

Hey. Interesting question and something I'm going through right now.
I've always chosen full DBs in the past, but someone mentioned Airtable to me and I thought I'd give it a go.

Here's what I've found.

Firebase

• You can model data how ever you like.
• There are various ways to query data
• Database view is a more "under the bonnet" look, you see raw data
• Images are stored in a separate procedure and place
• Real-time data! (think messaging apps)

airtable

• Data is in table (like sql)
• There is no way to query data, you fetch it all, or per page, but no queries (I might be wrong, but I don't remember queries)
• Database view is really good, nice sorting and filtering options,
• Images are viewed and uploaded right there in the table

Conclusion

Firebase and other proper databases and storage options for full scale products and webapps etc.

Airtable for simple little apps and websites. It's actually really nice to use, but very limited.

I've built an ecommerce webapp on top of airtable, which could be ready for launch soon :D

Google Sheets are for humans, as the Google engineer blogs about it. And human are operating fuzzily and so are the tools. Spreadsheets like software (Excel, GSheet etc.) are designed to balance the the operation fuzziness and rigid logic. Because of that, these tools are so complicated and have so many features built in so that humans can use them.

A while back I was working in the finance space and was tasked to build a simple service to process Excel documents. It was not an easy task. Excel has many features that could take lots of dev efforts to develop the parsing logic to be just on-par with it. I blog about my experience if you are interested.

Anyway, my two cents is, depending on the business, if the data is not that mission critical, opting for Airtable or GSheet is fine for its good human UI to operate on data. But once production systems depend on the data to be correct, storing a RDBMS (mysql, postgres) is not avoidable, and we have to live with the pain of dealing with human data entry mistakes, or building the data UI too rigid that users complain all the time.

I use it to store and retrieve data for webflow projects, its just a very fast way without any setup so it works for LPs, MVPs, prototypes but fails when the complexity is added.

Google Sheets for finance, I can tabulate it on a big screen then consume it on a mobile app, not saying it's ideal. I'm a full stack dev though so I can make my own API if I want. But Spreadsheet is easy to use/write into.