Database access in pro plan

[Fernando_Lopez1]

Before the change on prices and plans, the database feature was enable in PRO plan. Please I request to reconsider to enable again this feature in the PRO plan.
The Business Plan is too expensive for starter app developers and for the clients in America latina.

[Grant_Stead]

Oh wow, really?
It used to be pro… Huh…

[Grant_Stead]

@Jon_Melo we’re working on some pretty cool stuff. (We’re still in dark mode, announcements pending.) Feel free to DM me and we can talk through some options.

[WillowMobileSys]

Jon_Melo:

1 - sensitive client data being stored in a spreadsheet.

In your experience, would you say that Google Sheets/Google Drive has the same level of security as Excel 365/One Drive?

I believe both have strong security. They both have taken measures to promote multi-factor authentication as well as alerts for suspicious activity.

AppSheet does have a few features to help further secure sensitive data such Device side encryption, file and image URL signing and marking columns or even the entire app as “sensitive”. All are available in the Pro plan. Check those out if you haven’t yet.

---

Jon_Melo:

2 - having to manage many spreadsheets as opposed to 1 database.

Due to the large amount of data needed for my app, I need to set up one application/spreadsheet per client.

I could go on for days on this topic but here are the two main questions:

The first question is what is large? Second, how many clients?

As noted data partitioning is only available in the business plan. But there are other things to help manage data across multiple clients.

1. Security Filters allow expressions in each app table to limit the data to only the client of the logged in user.

2. Copy of the app and the underlying data is easy to achieve but does require managing multiple sheets and apps.

3. If speed is the main concern, one often overlooked process that should always be considered is archival of data. In most apps, there is usually a small percentage of the data needed for daily use. The rest, if needed at all, is only looked at occasionally. I prefer to archive the older data and make it available in a separate basic, history only app.

[Bjarne_Allerup]

WillowMobileSystems:

If speed is the main concern, one often overlooked process that should always be considered is archival of data. In most apps, there is usually a small percentage of the data needed for daily use. The rest, if needed at all, is only looked at occasionally. I prefer to archive the older data and make it available in a separate basic, history only app.

Hi,
As I was following this thread, I saw this comment.
Since I have a similar need: few data are used daily but many are saved for historical reports, so I thought I would ask about how to archive data in a separate spreadsheet for use with a special “History Report” App.

[Lucinda_Mason]

I have an archive system set up that works for me. I talk about it here: Design question: Archive old data to another spreadsheet vs using security filter - #14 by Lucinda_M...

[WillowMobileSys]

Sure! I would refer to Lucinda’s post above first. I am aware of her archival process and I understand it works very well for her

Basically you would use AppSheet Reports within your “History App” to move the data. It would have access to BOTH your main data sheet and the archival sheet. Then create a Report rule that run’s on your desired schedule - daily, weekly, etc - that:

• detects the rows to be moved from the main sheet
• copies them to the archival sheet
• Deletes them from the main sheet

The complexity of your data structure will drive the complexity of this copy process. For example, If you have Parent/Child relationships, you’ll likely need to archive both so you’ll need a set of actions to handle both. It can get even more complicated if you want to archive only a few child records. BUT, it is all doable!!

---

(NOTE:You would NOT want to place the archiving in the main app as this would force that app to have access to the archival sheet inflating the app’s size.)

---

There are other ways to perform the movement of data. Many cloud platforms have their own scripting language or access to one that can be used.

You can create a scheduled script on that platform to move the data between sheets. Then connect your “History Report” to the resulting archival sheet.

[1minManager]

I think, in line with the comments made above, that this is potentially a false economy on Appsheet/Google’s part. Surely they stand earn more money by offering free connections to Google SQL instances rather than pricing 99% of their Appsheet customer base out of this? I have clients that would gladly pay £100 per month on top of the license cost if their App was faster via SQL. But paying $5000+ as an annual cost is not really an option for my clients

[Henry_Scott]

@1minManager Amen It is a cashflow discussion with Customers

[WillowMobileSys]

1minManager:

But paying $5000+ as an annual cost is not really an option for my clients

Keep in mind that the $5000+ annual cost (if AppSheet still honors it) is not per client. It is per database connection, under which you can have as many databases as your db cloud service allows.

If you can charge 100 pounds per client for SQL access, then you would only need 3 clients to break even.

Of course, there are the charges for the cloud services themselves and then depending on the overall data usage you would likely start to incur data charges. But when all told, you would need maybe 5 to 6 clients at the 100 pounds/month to make it business worthy.

Also, consider trying to move the clients into a single account under which you can get per user bulk license pricing to cut costs that way.

If you have many clients and are looking to include database capabilities, contact a sales rep at AppSheet. They are very good at trying to accommodate your needs as affordable as they can - at least that was my experience pre-Google.

[Elijah_Magrane]

I think the larger point is that it is completely cost prohibitive for some clients, especially considering it use to be a feature that was included in the PRO plan. For example, we have about 10 PRO licenses, there is no way I can justify $5000 USD/year to the CEO. Especially considering the annual cost of our 10 PRO licenses

If there was a more a la carte structure, however, (say an extra $5/user) that might be different. In my view they are missing out on potential income

[WillowMobileSys]

Elijah_Magrane:

I think the larger point is that it is completely cost prohibitive for some clients

I agree … but 1) Is it needed for those clients? 2) If so, what would it cost for them to have it done another way?

Don’t get me wrong. I am all for lower and affordable pricing if AppSheet can find a way to do it on the cheap. I believe it might be a while before they can provide those lower price points.

[pravse]

So this one is a bit different from the other feature requests — it is more of a pricing/packaging request.

Just to be completely clear about it, we totally understand and appreciate the ask. And this is on the mind of the people who are think about AppSheet product pricing here at Google. Beyond that, let me just say “no-comment” and move on to commenting on other feature requests — I can be much more transparent on product features.