Announcing AppSheet database General Availability!

ShirleyN · 06-21-2023 10:45 AM

Hello AppSheet Community!

We are excited to announce the General Availability (GA) of our native data store: AppSheet database. Our goal is to blend the simplicity of a table-driven data editing interface with the performance and scale of a relational database for non-technical users. Thank you for providing valuable feedback and suggestions during our Public Preview. With the launch, here are some updates to keep in mind.

Usage limits

First, it’s important to stress that existing data will not be deleted. Even if you are over the usage limits, data can still be accessed in the database or through a connected app. We know that the community has been eager to hear more on this topic, and we appreciate your patience as we finalized the details.

These are the limits per AppSheet plan per user:

Free trial	Each user is entitled to: 1,000 rows/database and 5 databases
AppSheet Starter	Each user is entitled to: 2,500 rows/database and 5 databases
AppSheet Core	Each user is entitled to: 2,500 rows/database and 10 databases
AppSheet Enterprise Standard	Each user is entitled to: 200,000 rows/database and unlimited databases
AppSheet Enterprise Plus	Each user is entitled to: 200,000 rows/database and unlimited databases

The following technical limits apply:

100 columns per tables
20 tables per database

We are committed to scaling storage to extend these technical limits. ~~We will be increasing the technical limitation to~~ ~~100k rows per table in the coming months and then more later in the year.~~ As of 10/13 we have scaled technical limitation to 250k rows per table! Usage limits have not been updated, stay tuned for more later this year.

Performance

During testing, AppSheet database was faster than Sheets for processing adds, updates, and deletes of larger tables. In other words, the performance benefits of AppSheet databases are more apparent for a table with 50,000 rows compared to a table with 1,000 rows. AppSheet databases also have better support for concurrent edits.

It’s also worth noting that quick sync is enabled by default for all apps backed by AppSheet databases, even for security filters, so data updates automatically for app users..

There are many factors that can affect app performance such as expressions, virtual columns and the data source. AppSheet databases were built with performance and scalability in mind and this remains a priority.

Feature updates

The biggest feature update since the Preview release is the database management feature, which can be accessed via the new ‘Database Info’ tab on the AppSheet Account page.

It provides access to the following:

Database Name: Displays database names and links for all active databases.
Connected Apps: Shows all apps connected to each database.
Table Usage: Shows all tables along with row counts for each table.
Logs: Shows all database events related to data maniputlation including all Add/Copy/Change/Delete. It also details when and by whom a database was accessed
Status: Shows Active and Deleted databases (with an option to restore within 30 days).

Another important feature that was published just after the Preview was Import from Sheets, which allows users to create a database using the structure and data from an existing Google Sheet.

Some of you have also been asking about the Row ID column that’s automatically generated for each AppSheet database table. It’s hidden by default to simplify the experience but it can now be added as a read only column through Metadata > Row ID.

Looking ahead

In the coming months, our primary focus will be on scaling capacity and performance. We’re also working on resolving some known issues in the coming weeks:

[Now Fixed] Changing the “Source Path” of a table through Table settings in the App editor may cause errors. Instead, change your app’s data source by deleting the old table and adding the new one through the Add data flow.
[Now Fixed] ~~The Row ID column is currently not visible for the 'call a process' step when setting up bots~~
Manual changes within an AppSheet database will not yet trigger automation

We hope this community post inspires you to try out AppSheet database for your use cases and to stay tuned as we improve the feature! To migrate your apps, please see migrate to an AppSheet database.

Thank you,

AppSheet database team

Ratatosk

Cool. But the appsheet core numbers cannot be right? Only 10 databases?

bsk2

And to add to that question...here is a specific scenario:

20 Appsheet Core Users with one Appsheet DB and 10 tables in the DB. Current state, please answer for following.

1) How many max rows per table? Please provide how this is calculated.
2) How many max rows per DB? Please provide how this is calculated.
3) How many tables per DB? Please provide how this is calculated.

Thank you.

ShirleyN

@bsk2 First a bit of context here should help. We chose rows/database as the unit of measurement for pricing because we wanted to give database editors flexibility in use- as long as it's in line with the technical limits. For some plans, users may not hit the technical limitation on the number of rows a table can have in which case it's up to them how to distribute rows across tables.

1) For Core plans, each database can have a max of 2,500 rows. The database editors can decide how to split that up. For example, there could be one table with 2,500 rows (this is well below the technical limitation) or there could be 5 tables with 500 rows. Rows per table is calculated by counting the number of rows in a table.

Alternatively, if a user had an AppSheet Enterprise plan they would be entitled to 200,000 rows/database. However, they would not be able to put all 200,000 rows into one table because that exceeds the technical limit.

2) Answer is similar to the first question: 2,500 rows per DB . Rows per DB is calculated by counting the number of rows across all tables in a database.

3) The database editor can have as many tables as they would like as long as it is lower than the technical limit of 20.

Tom2023

@ShirleyN wrote:
1)For example, there could be one table with 2,500 rows (this is well below the technical limitation) or there could be 5 tables with 500 rows.

A max of 2,500 rows/database is way too small for production. 2,500 rows/table would be a more reasonable limit. Please consider it.

dbaum

@ShirleyN / @zito, this is a key question. The phrasing in the announcement's Usage Limits table is ambiguous regarding whether "per user" applies only to the databases per account or also to the rows per database.

@ShirleyN wrote:

2,500 rows/database and 10 databases per user

In other words, (2,500 rows/database and 10 databases) per user or (2,500 rows/database) and (10 databases per user). For instance, does an account on the Core plan with 20 users allow (20 * 2500 = 50000) rows/database?

ShirleyN

Thanks for the callout @dbaum , I'll update the wording. Each user is entitled to 10 databases and each of those databases can be a maximum of 2,500 rows.

dbaum

@ShirleyN wrote:

AppSheet databases were built with performance and scalability in mind and this remains a priority.

Glad to know this. That's the crucial focus, along with making the technical and plan limits as high as possible (even 200K rows is limiting for some use cases).

@ShirleyN wrote:

It’s also worth noting that quick sync is enabled by default for all apps backed by AppSheet databases, even for security filters, so data updates automatically for app users..

Is there an explanation available regarding:

Any constraints regarding security filters characteristics that preclude Quick Sync?
How this plays out when some of an app's tables use ASDB and others don't?

Karimmc2

Very much agree with the row limit, mainly because the advantage to this product would be in its performance over Sheets and it only make sense for large tables.

preethamm

@dbaum wrote:

Any constraints regarding security filters characteristics that preclude Quick Sync?

How this plays out when some of an app's tables use ASDB and others don't?

- There are no security filters restrictions today. Since we own the backend, we just do a complete sync under the hood. So it handles all security filters.

- This applies to apps that use ASDB only. This will switch back to opt-in based quick sync if there are other data sources.

@dbaum

takuya_miyai

@ShirleyN
Congratulations!
I'm happy to add a new AppSheet product family!🤗

@ShirleyN wrote:

Manual changes within the database will not yet trigger automation

I felt that it would be better to have this one explicitly stated "wihin the AppSheet database".

This is because there are cases where it is difficult for citizen developers to understand whether the word "database" refers to the general Database or the AppSheet database.

ShirleyN

Thank you @takuya_miyai ! Good catch, I will update the post.

Eduardo_Jr_Vill

What's the difference between

2,500 rows/database
50,000 rows per table

How many rows or records can we have in a database?

AppliSuite

I couldn't understand the same thing.

For example, with the AppSheet Core plan, creating a table with 50,000 rows will far exceed the database limit of 2,500 rows.

Please explain, @ShirleyN

zito

Two different limits - one is a technical limitation on a table, each individual table cannot exceed 50k rows.

The limitation on the database by plan is total number of rows across all of the tables in a database that is enforced based on the user's plan type.

AppliSuite

Maybe it's my stupidity, but I didn't understand your explanation.

The explanation below gave me some understanding.

https://www.googlecloudcommunity.com/gc/Announcements/Announcing-AppSheet-database-General-Availabil...

Even so, the explanation of "These are the limits per Appsheet plan" and "The following technical limits apply across all plans" is difficult to understand. There is no explanation of "technical limits" either. English is not my native language, but it is still difficult to understand.

The problem is that the "50,000 rows per table" limit is only relevant to the Enterprise plan, but it's stated as "The following technical limits apply across all plans" to apply to all plans. I think it's about being there.

If you add one column to the "These are the limits per Appsheet plan" table and explain it like the following, wouldn't you be confused like me?

Free trial	1,000 rows/database and 5 databases per user	100 columns per table 20 tables per database
AppSheet Starter	2,500 rows/database and 5 databases per user	100 columns per table 20 tables per database
AppSheet Core	2,500 rows/database and 10 databases per user	100 columns per table 20 tables per database
AppSheet Enterprise Standard	200,000 rows/database and unlimited databases per user	100 columns per table 50,000 rows per table 20 tables per database
AppSheet Enterprise Plus	200,000 rows/database and unlimited databases per user	100 columns per table 50,000 rows per table 20 tables per database

peterson

Humm I guess I didn't like this. But I understand. It would make more sense if Appsheet's database could receive files and attachments in it. We could upload multiple images and files, if we could work with videos.

Marc_Dillon

I'm very surprised by these row limits. I can't see myself ever considering using ASDB with these in mind.

scott192

Yep, same here!

zito

There's two dimensions here, the technical limits and the plan limits. On the technical limits side, 50k (as Shirley said) is a starting point, and even 50k is large enough to hold 90%+ of the active appsheet apps today, though obviously the most critical apps are going to be dramatically larger than that. But our goal is to get into the 1M+ range, at which point we are essentially at Sheets levels of scale with better performance and concurrency. That's not a knock on the Sheets product or team, we work closely with them, but they're not prioritizing being a data store with potentially thousands of concurrent users.

On the plan side of things, this is also a starting point. There are many more Core users than there are Enterprise, and so we wanted to keep an eye on usage and capacity for those users. There are also some upcoming enhancements to Core that we think will drive increased adoption and scale for those users.

From a policy perspective, its very easy for us to increase the limits, but very difficult (or impossible) to decrease them. Consequently, it makes more sense for us to start the limits low and watch utilization than to start them high and risk capacity or cost issues.

Happy to talk more about the pricing process if there's interest, but I think I'm the rare person who gets really excited about pricing models.

Ratatosk

I understand your approach. Thank you for pointing this out. 🙂

I would say that the main issue for me lies with the growth of data over time.
With such a small hard limit it would be very difficult to maintain, when we have Core plan with 50-100 monthly users.

It also diverges from the starting point, where app features was what differenciated the various plans.

There is also a cost-limit when we have 50-100 monthly users on what we consider an internal supporting software, so if prices on Enterprise plans do not change, it is not a viable option.

Karimmc2

I am concerned about these row limits too. The main advantage of making a transition from Sheets to ASDBs would be in performance, and it starts to get noticeable around 50K rows, which is when you start to realize you really need a performance boost, so with the current limits it is pointless to migrate from Sheets to Databases.

Seems like the team is pretty aware of this, @ShirleyN mention scaling at least twice in the post and if it ever gets to 1M+, as @zito says, it would be a great product, just by the performance alone, without even touching on all the other features.

With that said I agree that, at least in my use cases, anything below 2.5K is pretty much useless because we’re talking about tables that are rarely updated short lists and for the performance impact of that It would be far more practical just to keep using Sheets, or even a fixed list within the expression or the editor itself without using any data source at all.

The tables that truly start to ask me to migrate them from Sheets to some other solution are well over 50K and could easily get to over 250K rows without using them as data warehouses, just for operational data.

I think that whenever it gets to 200K to 250K rows per table then it could be a fairly reasonable number for a user that really needs that performance boost and from there we could build a data flow solution to every once in a while clean up the table from data that could be moved to a warehouse.

Of course no row limit will ever be sufficient if someone plans to use this as a warehouse that is going to keep growing forever, but only using the day to day operational data ( at least for a user with a similar use case as mine which is a single company and a pretty small set of users) I think the numbers would be something like this:

* 100K+ rows per table for it to be functional and attractive enough to replace the existing solution

* 250K+ rows per table for it to start to shine

* 1M+ rows per table and a noticeable performance increase, ok we’ll upgrade the plan.

IMO

zito

Thanks for the feedback, I agree with your general assessment. It's worth noting that the folks here are not the typical AppSheet user in terms of both their expertise and their usage patterns, so we expect that many of the early users will be people building for small team use cases where 50k rows is more than enough to get started and we can grow capacity as usage grows.

@Karimmc2 wrote:

With that said I agree that, at least in my use cases, anything below 2.5K is pretty much useless because we’re talking about tables that are rarely updated short lists and for the performance impact of that It would be far more practical just to keep using Sheets

Something that we didn't highlight in the original post because it's somewhat orthogonal to the core goals of ASDB, but a decent percentage of users struggle at connecting a Sheet to their app, even for experimentation and learning AppSheet. ASDB even with lower limits potentially helps to address that (again, not the core goal, but I am interested to see whether it has an impact).

But yes, I agree, I eagerly await the day when ASDB scales sufficiently that its essentially a non-issue, and I think your assessment of the limits matches mine.

Chern

My team and I just spent several months migrating from Google Sheets based apps to ASDB and designed a bunch of AppScript projects to keep our data to less than 10k rows per table only to find that the ASDB feature was GA-ed with the limits implemented essentially crippling our existing apps as they all exceed the limits and rendering our efforts pointless.

JPAlpano

This is true. Why would I want to migrate to Appsheet databases that will only give me a max of 2,500 rows, when a Google Sheet gives me upto 100K of rows?

Isn't the database supposed to be more powerful than Google Sheet?

Ami

Perhaps there should be a new payment plan specified for ADSB meaning pay as you grow. I believe it's not hard to run a script that checks usage and can assess or predict usage based on usage history.

Hocappsheet

I don't think it suits me at all, it's too expensive

AppliSuite

@ShirleyN

I have a problem during data migration.

Conventionally, when using Google Sheets as a data source, set the "ID" column to KEY and generate a unique value for Initial Value using the UNIQUEID function.

The KEY value set for this "ID" column is not consistent with the AppSheet Database RowID.

When migrating from Google Sheets to AppSheet Database, the KEY value of the "ID" column cannot be inherited or replaced with RowID. Therefore, I cannot replace the data source of an app that sets "Ref" as the KEY value for the "ID" column with the AppSheet Database.

Is it correct to assume that data migration from Google Sheets is impossible as a usage of AppSheet Database?

ShirleyN

Hi @AppliSuite , how are you migrating your app? If you copy the entire app and choose AppSheet database, it should still save your preferred "ID" column as the table key, and references should still work like before in the app. The "ID" column will still have the same initial value function UNIQUEID().

The key column can be changed inside the app editor at any time but this means you will not be able to set references from the AppSheet database UI, making it more similar to Sheets. More details here: https://support.google.com/appsheet/answer/10106672?hl=en&sjid=4515579216879630996-NA#system-generat... Copying the entire app would be the preferred method.

AppliSuite

Thanks for your replying, @ShirleyN !

By copying the app as you said, the data migration from Google Sheets to AppSheet Database was successful. Some "Ref" type columns set in the app also work fine on the app.

"Ref" type columns on the AppSheet Database UI are related by RowID, so this will not work. I understood that the "Ref" type column in the AppSheet Database UI after data migration does not work as a Reference and is almost like a "Text" type column.

After the data migration, I understood it would be fine to just use the AppSheet Database as a backend data source just like Google Sheets.

Thank you very much.

WillowMobileSys

@ShirleyN wrote:

Each user is entitled to

It seems the confusion is who is the "user" this refers to? App Creators or licensed app users?

Below are the terms that AppSheet has decided on within the Table settings so we should make sure we use these same terms in all communications and documentation

ShaunTheSheep

Im trying it out and it seems very useful. Just a few questions. Is there a way to change currency of price from USD, to NZD for example. Also i dont see a way to reference other tables with a type of formula like SUM all prices less than 0.

Alan_Thorp

I've been quite excited about the release of this product, but currently these limits are too limiting.

In it's current format I feel like this will work well for people just starting out, or small apps that are not used much. It won't work for me with the larger apps that I have made. I have one table with 25,000 rows. I'm on an AppSheet core plan, so couldn't even fit this in a database. 20 tables is not enough for my larger apps either. I feel like the row vs column limit is a bit unbalanced as well. My 25,000 row table has 12 proper columns, plus some spares, with very little data in each field.

If I increased to an Enterprise plan I will probably take the opportunity to just use a MySQL instance. Other than the interface I don't see much advantage over an SQL database of whatever flavour.

It would be interesting to be able to split/partition an app across multiple databases. This may make it more attracive than an SQL database.

I'll keep an eye on how this develops.

takuya_miyai

Hi @ShirleyN and @zito

I have two question.

Q1.

Is there a way to see the status of AppSheet database sharing across the organization?
For example, I would like to know if one AES user is sharing his AppSheet database with 100 other people.
(even though the contracted license is only 20 Lic!😂)

Q2.

Is the ability to manipulate the AppSheet database directly from the AppSheet Editor on the roadmap? There has always been a challenge for citizen developers to use spreadsheets and the AppSheet Editor differently. I remember that one of the missions of the AppSheet database was to address that issue. Is the development of that functionality still ongoing?

Thanks.

ShirleyN

Hi @takuya_miyai ,

For Q1, unfortunately there is no consolidated view for seeing share status of a database right now. The best way would be to go to the database's audit logs, and filter by "Add/replace database sharing" events to get a sense of how many people have access to the database.

For Q2, this is still an ongoing effort. It is quite complex and there are many edge cases to consider so we want to be thoughtful about it. We've also been looking at feedback from users to try and understand which part exactly is the challenge.

takuya_miyai

Thank you @ShirleyN

@ wrote:

For Q1, unfortunately there is no consolidated view for seeing share status of a database right now.

I understand that there is no functionality at this stage.
What I am wondering is, if the AppSheet database is shared, does that count as a licensed user and will it be billed?
GWS users routinely share and use Sheets and Slides. if ASDB is shared in the same way, will it result in unintended billing?

For Q2, this is still an ongoing effort. It is quite complex and there are many edge cases to consider so we want to be thoughtful about it. We've also been looking at feedback from users to try and understand which part exactly is the challenge.

I understand that functionalization is still being planned.

Not specific to ASDB, but where does the AppSheet team feel feedback should be collected?
For example, I feel that collecting feedback in this Announcement thread is not a very effective way to collect feedback.
In fact, I personally think it would be desirable to collect feedback along with requests in the Feature idea.

@zito
@Roderick

IanCharlesBlack

I have to agree with the general consensus...although I love a number of AppSheet's database features, with these level of column/row limitations, I cannot even begin to consider migrating.

Rather disappointed. I was really hoping for an increase for core users when compared to the public preview, as was kind of insinuated...really wanted to make the switch.

Hopefully this is reconsidered, because again, love the platform.

Rifad

Please dont COPY the app from an existing app in production to this new appsheet database. It will just break your entire app in production.

1. I copied the app and started testing with below setting. It just copied only couple of tables to new database (20 tables) rest of tables remained in existing production google sheet itself (did not copy to new googlesheet/database).

2. I kept testing the newly copied app by making bunch of changes to test the performance and advantages over google sheet. This suddenly stopped my production app. The issue was shown below. An empty column was auto added with random ID in all the tables of production database. (I didn’t re-check database connections before making changes. Appsheet default behaviour is to copy database to new spreadsheet)

3. Managed to delete all those unwanted columns and fixed the error in production app.

4. Performance wise I did not see any difference between both apps using google sheet and database. Sync speed and update speed remains same.

Koichi_Tsuji

@ShirleyN There should be another limit in terms of max number of characters per cell (field) of ASDB.

It looks like 49826 as per my own testing. which is slightly less than Google Sheet.

From my point of view, Google Appsheet team seems to be a habitual liers, sorry to say again, but this is true.

I sincerely hope a return of the original management team of Appsheet to listen to our voices rightly.

Anyway, Google is promoting ASDB is scalable and bring the benefit to scale the app data sources, comparing with the given available circumstances. However, it is actually false statement, i have to admit. Google Sheet is more scalable, stable, and easy to handle.....It is better to stop to announce the false statement to the user , as it simply cause the nagative impact, i.e. the mis-understandings, dissapointment, mis-guidance, lies, etc etc. Not sure where Google Management team wish to bring us. Unless the Google could not get the full support from the active users, the growth of the platform is going to be capped.... This should be learned in the school, isnt it?

We observes the management failure of AppSheet team (sorry to say) after the aquisition by Google in 2020. Not much benefit and values were added to the users, but Google enjoys its own play and games (most of them is not in line with the expecation of users), while the benefit of the users leaves behind. Im sorry to say but this is true as it looks like the Google AppSheet team seems to be habitual liers as it keep pushing the false statement all the time......

Koichi_Tsuji

What Google does say, but the reality is totally opposite kinda things: -

- This community place is monitored by Google staffs all the time to support you. ----- No . this place is left to the volunteer supporter to get active. No Google skillfull stuff for support (we know it is not avaiable) supervising.

- Give us your feedback for new features. ---- We know the Feature request category never being reviewed and prioritized. Google internal interst is prioritized, which result in the new features which is not broadly used by the community.

- We hear the support desk and services are enhaunced, but we all know the personnels in support desk is with less skills and knowleges about the appsheet. They should be educated not to support the end users, burt focusing on closing the ticket.

- This is no-code platform, but keep pushing the users to use the coding tools such as Apigee etc. This is the departure of the original concept where the AppSheet was born. Google is bringing the platform to coding/low coding platform, while forgetting teh appsheet is no-code plaform.

- Apparently, Google is ruling out the non-GWS users from appsheet. AppSheet was eco-system before, i.e the compartible with any other plaform and services, but currently only friendly with GWS users.

It it late at night my time. I stop over, although there are tons of other negative observations.

All in all, this is management failure. Time will tell.