Google Spreadsheets and Python

Based on the read-write characteristics of every website I've ever built I'd say "mostly read-only" is a pretty good characterization.

Even things like forums have many, many page loads than new posts.

Regarding your claim about SLAs - there actually is an SLA for all of the paid Google Cloud products - e.g. the following would apply for GSuite, which covers Google Sheets:

https://support.google.com/work/answer/6056635?hl=en https://gsuite.google.com/terms/reseller_sla.html

If you mean the free products e.g. Google Sheets with a consumer account - AFAIK, there isn't a contractual SLA per-se, but the uptime is pretty good =).

You can also see a status dashboard with historical status here:

https://www.google.com/appsstatus#hl=en&v=status

RSS feed link is at the bottom of that page.

(Disclaimer: I work for Google Cloud, on the Drive/Docs/Sheets side of things).

I'm going to have to be a contrarian on this one.

On my team, we absolutely loathe Google Spreadsheets with a passion. Not necessarily the product itself. It actually is a truly capable and nice spreadsheet program. However, it encourages some extremely bad uses.

Because of the low friction of creating a spreadsheet versus, say, a database, business users have started using it as a substitute for something that should probably live in a database. For instance, I'm thinking of a particular portion of our sales organization that kept their business hierarchy in a Sheet, ie x person is on y team. Now, when you want to do analysis on the data you now have to use something similar to this library to retrieve the data and return it in a dataframe, which then pipes into the rest of your analysis and you end up with a finished product, be it a dashboard or some job.

What always happens is that you write your analysis, set it up to run regularly, and all of the sudden, three weeks later, you start receiving exception emails on the script. When you investigate it, inevitably some jackass business user upstream altered the "schema" of the document, breaking your downstream analysis.

In addition, once you have hundreds or thousands of these scripts running repeatedly, all reaching out to the Google API and in some cases retrieving 100s of MBs of data, Google very quickly rate limits you and you end up with dozens of scripts that broke.

Sheets is great for analysis and one offs, but you have to push back on your business users who will constantly try to use it as an operations platform because they don't know any better.

- "I need to see an analysis of xyz data."

- "Ok, where does the data live?"

- "Well, all of the facts come from this SQL table, and we pull from this web service, and finally we run it through this lookup table we maintain in Google Sheets."

- "Nope. Come back to me when you put that data somewhere else. Spreadsheets are not databases."

Back at my previous company, which was a travel startup, there was a list of curated vacation packages that were created for every weekend. So, the itineraries team used to spend 5 days designing the packages and getting vendors on board, and then they used to fill up a google sheet with the details in it and the devs used to run a script, which used to populate this rows in the database and make any other updates required and it used to show up on the website. The reasons why this worked so well for us:

1. There were at the most 30-40 rows. Google Spreadsheets works amazing for small table sizes (although not as small as 30-40, I'd assume upto 1500-5000 should be fine as well).

2. All non-dev teams were EXTREMELY comfortable with Google Spreadsheets. For people with non-engineering backgrounds, a spreadsheet is an amazing, low-barrier entry to structured data which I believe is what made this solution amazing.

3. The dev team was completely removed as a dependency, and we had staging environments where they would run it first to ensure it was working properly, so a dev could be engaged only if their spreadsheet run wasn't working as expected or due to some other issue. The previous method was a huge email sent out to the devs, who would handcraft it into a JSON, which would then be passed to a script and then written to the database. This required every run to be effectively final.. there were only so many times one could engage a dev.

4. While we had to engage a dev to execute the script, it actually is very easy to integrate a menu option within the google sheets interface itself (if you are using Google Apps) for your domain, which would say something like 'Deploy to Staging', although we never got around to actually building this.

For startups where product turnaround time is required to be short, this works as an amazing solution as it makes so easy for non-tech guys to input data into the system. While there is no doubt that a fully developed panel for these operations would be the best solution, one doesn't always have the luxury of time.

I read somewhere that AirTable is deliberately only targeting "human scale" data use cases.