Announcing AppSheet database General Availability!

[ShirleyN]

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?

[dbaum]

@ShirleyN

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

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?

[takuya_miyai]

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

@ShirleyN

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.

[Karim_Mena_C]

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.

[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

[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.

[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.

[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.

[Karim_Mena_C]

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

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.

[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.

[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

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?

[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-Availability/m-p/605850/highlight/true#M7147

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

[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.