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

[takuya_miyai]

@ShirleyN 

Could you please tell me the rules for generating Row IDs for the AppSheet database?

The reason for my question is that I would like to know the extent to which Row IDs can guarantee uniqueness.
As far as we can see, they are generated randomly using alphanumeric symbols, and we believe that it is practically impossible for identical keys to be generated.
However, I would like to know if it is not merely random, but if uniqueness is guaranteed within the same database.

Related AppSheet help point

https://support.google.com/appsheet/answer/10106672?hl=en&sjid=6138640340618138736-AP#:~:text=Row%20....

[preethamm]

RowIDs are encoded UUID v4 values(RFC 4122, Sec. 4.4.). This translates to 122 bits of random bits: total of 2¹²², or 5.3×10³⁶ (5.3 undecillion) possible values. Chances are conflicts very very rare.

[takuya_miyai]

Thanks @preethamm .
I understand now about the PackedUUUID specification. I don't think there is any practical problem at all. If I could make it a unique ID in the database, I wanted to generate permalinks like this

https://www.appsheet.com/start/<<APP_ID>>/<<Database_ID>>/<<Record_Key_Value>>

It would be useful to be able to define short permalinks that explicitly specify a specific record, e.g., for referencing from other systems.
In some cases, URLs indicating current unique records are too long and cannot be stored in some systems.

I understand that this is difficult at this time, but I hope that another feature of AppSheet will make this possible.😃

[preethamm]

AppSheet Database UI has an option that might help you here. Right click on the cell and copy the url to row. This does not link to the app though.

Format of link:

https://www.appsheet.com/dbs/table/ <tableid>/row/<rowid>

[Ravshan]

I have a large database of about 70000 rows, I didn't expect such a limit 😟

[WillowMobileSys]

I do not believe that the AppSheet Database is intended, at least at this time, as a replacement for large databases.  I believe it is intended for prototype and small deployed apps.  Maybe over time, as with most Google services, the limits will increase.

The main issue for those who wish to test an AppSheet app connected to a database, is that there is no "good" FREE way to do so.  The AppSheet Database feature fills that gap.  BUT, an AppCreator should be prepared to switch to a paid database provider once their app is mature enough.

[baptisteV]

Thanks for the good news ! I am still wonder, Does Appsheets database will replace Google Tables ? Or Google tables will be a complementary product ? Thanks ! 

[Joseph_Seddik]

I'm currently actively weighing options to migrate my client's app to a database. With the new ASDB in GA, according to my understanding, my options would be:

1. Maintain current Core Plan and use ASDB:
--> Taking into account a 2500 rows/db limit, with simple math I realize that I wouldn't be able to keep a single-year's worth of records in the db, unless app users collectively add ONLY 6-7 records to the db each day!!!! That's way below the current usage needs. 

2. Adopt an Enterprise Plan
---> I don't see any benefit in migrating to ASDB compared to a usual SQL one. Is there really any?

In both scenarios, I see ASDB discarded. 

If my understanding is incorrect in anyway, I'll be thankful to those who'd correct/orient me. 

[dbaum]

---

@Joseph_Seddik wrote:

I don't see any benefit in migrating to ASDB compared to a usual SQL one. Is there really any?

---

ICYMI, the following is a factor to consider:

---

@ShirleyN wrote:

quick sync is enabled by default for all apps backed by AppSheet databases, even for security filters, so data updates automatically for app users

---

[Joseph_Seddik]

---

@dbaum wrote:

ICYMI, the following is a factor to consider:

---

We don't have any need for near-real-time updates, besides and more importantly, I would NEVER get rid of my Virtual Columns only to enable Quick Sync. 

[Rifad]

You are right @Joseph_Seddik for me it looks like a marketing gimmick or more like engineers wanted to waste time on something unimportant. After Google acquisition appsheet is left unattended most of the time by google. Just to meet target and show someone is working on something in their performance dashboard. From google as parent company perspective when the look down to appsheet all engineers are engaged in working on something. But is it on useful things so far ? No. I hope they realise fact that they are back in track with better upgrades and useful features for a business tool. This database limits looks like released for school kids to play with it rather than a business use case.

[Joseph_Seddik]

@Rifad I agree. It has been explicitly mentioned in this thread that they are targeting new apps, not apps in production, perhaps hoping those new users after a while would find themselves stuck with ASDB and be forced to acquire Enterprise licenses. 

[takuya_miyai]

Hi @Joseph_Seddik @Rifad @dbaum 

As a Developer, I agree with you all.

However, not to defend AppSheet, but as another way of thinking, I would like to see the ability to edit the AppSheet database directly from the AppSheet Editor.

@ShirleyN answered that my question.

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

For members who have been using AppSheet for some time, the separation between the AppSheet Editor and the data source management tool is natural and even considered rather easy to use.

But I also agree with AppSheet that that makes it difficult for some citizen developers to understand AppSheet.

I am sure there will be a variety of opinions on this point. And not being aware of the schema of data sources on a DOA platform like AppSheet may become a skill-building issue in the medium to long term.

However, I still believe that it will contribute to increasing the number of citizen developer users of AppSheet.

And perhaps we need to familiarize ourselves with the AppSheet database so that we can guide such citizen developers.

[Joseph_Seddik]

@takuya_miyai I agree with you and have nothing against ASDB, on the contrary, I was awaiting the GA to adopt it in production. Being a new product, I even fully, heartily support defining a low technical limit as a start then cautiously increasing it. 

The logical limits are just too prohibitive and are simply a deal breaker in my humble case. Seriously 1000 rows/2500 rows?!! Additionally presented as an alternative to some 10-fold practical limit in Sheets? 🙄

[Rifad]

---

@Joseph_Seddik wrote:

The logical limits are just too prohibitive and are simply a deal breaker in my humble case

---

Not in case of just ASDB look into various important thing like this Community (Downgraded to a worse option available in market and no proper volunteers) 

Chat support- Does not even know how to use Appsheet. Everyone sounds like a robot. No solutions. Takes months..

Its not just this.. Appsheet as a whole they dont have any logic anymore. As I mentioned

---

@Rifad wrote:

After Google acquisition appsheet is left unattended most of the time by google. Just to meet target and show someone is working on something in their performance dashboard. From google as parent company perspective when the look down to appsheet all engineers are engaged in working on something. But is it on useful things so far ? No.

---

[takuya_miyai]

Hi @ShirleyN 

The following link is broken.

https://support.google.com/appsheet/answer/10011560

This is the explanation page for Row Limit in the AppSheet database.

 

[ShirleyN]

@takuya_miyai sorry forgot to respond, the link should be fixed now. 

[Aurelien]

@ShirleyN 

As the AppSheet App information is available through Looker Studio connector, is there a way to access to AppSheet Database information from Looker Studio?

If not, is it planned? Do you have an ETA?

Thank you

[preethamm]

You could create an App from the AppSheet Database and use it in Looker Studio. There are no immediate plans to implement a direct connector from AppSheet Database  to Looker Studio.

[Aurelien]

Thank you @preethamm for your accurate answer. 

If ASDB comes to be used extensively, I cross my fingers that it will be possible 🙂

Two more questions, if I may.

1) I think it has been asked already but I don't remember having read a response so far: will ASDB have an API available for public use such as with Google Apps Script?

2) Do you have an ETA for ASDB governance policies for Enterprise plans?

Thank you in advance for your consideration.

[preethamm]

1) API: Is not in the immediate pipeline since you can use the current AppSheet API(via an app) to do this today.  Yes, as you mentioned, as the usage grows, we will reevaluate direct Integrations with Looker Studio and API.

2) Governance: we are actively working on it. No exact dates yet.

[Scott_Nesbitt]

Any news on Apps Script integration?  Almost all of my apps have at least a little Apps Script, so this is a dealbreaker for me.

Thanks

[Koichi_Tsuji]

@ShirleyN 

I m not really useing ASDB yet, but just testing to see if it is ready for production. 

Just create new ASDB by using export Sheet to ASDB. Then back to the AppSheet and change the source of the table from Sheet to ASDB table. Then the app is broken and collapse.  Even after changing the source from ASDB to Sheet back again, but the App is broken.  

All in all, ASDB is not ready to use in prod unfortunately.

[ShirleyN]

Hi @Koichi_Tsuji we released a fix for this today, if you don't mind trying it again you should be able to change the source through Tables Settings now. 

[takuya_miyai]

Hi @ShirleyN 
I was able to add records in excess of 50,000 rows in ASDB today.
Is there a situation where an extension up to 250,000 rows has already been released?

 

Note that this ASDB was created today by importing a CSV with 51,000 rows, but at that time it only imported up to 50,000 rows.
However, I was able to add records manually and it looks like the screenshot.

[ShirleyN]

Yes, we have rolled out the increase in technical limits to 250k rows for Enterprise plans! Thank you for the reminder to update the post. Docs should be updated as well. I will look into the import scenario. 

[takuya_miyai]

Thanks @ShirleyN !

I am just about to start a project to develop an application with over 50,000 rows.
I will fully test this on my end, but ASDB may be available.

It would be great if you could also investigate regarding CSV uploads that exceed 50,000 rows.🙏

[takuya_miyai]

Hi @ShirleyN 

I successfully created 250k records with automation.

 

I look forward the continued development of ASDB.🤗

Thanks and regards.

[Mode]

Is there a change in the core plan row limits already? Or it still stays at 2500?

[badcom]

Same question here

[WillowMobileSys]

@Mode @badcom 

I don't remember everything that was said, but there were updates provided concerning the AppSheet Database in the September "Office Hours" meeting.

You can find links to these meeting under the Events menu at the top of this page.  

The link for the September meeting is below:

Updates to AppSheet databases, INPUT functionality, and expanded access for Workspace editions 

[coldcoffee]

Hello! I'm trying to migrate a small amount of data from GoogleSheets to AppSheet DB, hoping it will improve my app performance.

I am unable to proceed past the import of a column of LongText.

The data was initially entered into the GoogleSheet via my AppSheet app. So it has passed through AppSheet's form handling process successfully already. It also displays perfectly in detail and form views of my googlesheet based app after saving the form.

The column type is LongText. Users copy and paste paragraphs of information from other sources. LongText allows it to retain a small amount of the formatting such as hard returns

AppSheet will not being to migrate the GoogleSheet at all (gives errors) unless I empty that LongText column. So I did that, I cleared the cells, migrated the googlesheet without the longtext and attempted to bring the longtext information in another way. I created a LongText column for it in the Appsheet DB editor and tried the following:

1. Copy/Paste the googlesheet column data into the AppSheet db editor.

• select and copy the cells in GoogleSheet. Move to db Editor, select the column and choose "paste"
• Immediate error
• AppSheet wants to interpret the hardreturns in the LongText as new rows
• DB Editor gives the error message: "cannot paste more than 500 rows" (there are just 70 rows)

2. Copy/Paste individual cells into appsheet db cells.

• select and copy an individual cell in GoogleSheet. Move to db Editor, select a cell and choose "paste"
• result is improper formatting
• Appsheet DB editor pastes the data across multiple rows and columns
• it still interprets hardreturns as rows and now additionally interprets horizontal spacing as columns

Is this a bug or is there a method I haven't tried yet ?

[Kusadi1]

The problem arises when we use action with the do: execute an action option. This really doesn't work

[Espegg]

So to recap, for Core users:

- How many rows per table
- How many tables per database
- How many databases

[ShirleyN]

@Espegg Each user in Core is entitled to: 2,500 rows/database and 10 databases. You can distribute the rows inside your database however, you like. 

[Espegg]

It is strange, I am in Core but I have created a table with 20k rows...
How it is possible?

[Landan_QREW]

Can these databases be connected to BigQuery?

Is there a query console to interact with the databases with a SQL framework?

[philippevg]

I am still waiting for an increase in table rows to be at least 100,000 rows/database for Core users. I won't start migrating data to an App with a native database until then. The current limit of 2,500 will never work for serious App development.
Note: I am an AppSheet developer for small/medium grassroots Non-Profit organizations that get the Core plan as part of the Google For Non-Profit Grant. These NGOs will never spend their much-needed donations on an Enterprise plan. If NGOs could connect an external database (Enterprise feature) they would use the MS Azure Grant to connect an SQL server. @ShirleyN is it possible to extend that feature to Google For Non-Profit accounts?

[takuya_miyai]

Hi, everyone.

I have checked the latest Read performance of AppSheet Database for use in a production app.

The conditions are as follows

• Same data in Sheet and ASDB, read in the same app.
• Row count is 200,000 rows
• Number of columns is 17
• However, ASDB has one more column for "Row ID" column.
• Permissions are all CRUD allowed for both.
• Those tables doesn't have VC.

The results are as follows: Sheet is still faster to read.

However, this is just reading all rows.
I really want to test the performance improvement for multi-transaction.
But that test is not easy.🤔

@ShirleyN 
@Aleksi 
@Koichi_Tsuji 

[WillowMobileSys]

Not sure how similar AppSheet DB's are to the typical relational databases.  We don't really have insight to that.  And I do understand that your test reflects the poor performance of ASDB.  ASDB's are still new and are progressing.

...BUT...

This single test is not appropriate to truly compare the 2 different datasources.  The test needs run multiple times because a single test could be skewed due to platform activity.

To truly compare, you also need to run tests at varying data sizes.  For example start small and then increase 5K, 10K, 25K, 50K, 100K, 150K, 200K, etc. running at least 5-6 tests at each data size to get an average. 

Running tests in the manner above will make sure you are getting the complete and more accurate picture of the strengths and weaknesses of an ASDB.

A side note for relational databases... 

In general, there is extra processing overhead to maintain primary and foreign key relationships plus possible other features such as Indexing, etc.  Thus a database will NOT be faster in all data size scenarios - in fact I suspect that ALL databases will be slower up to some threshold (which will vary by database service) and then will quickly surpass sheets once that threshold is passed.  Running tests with different data sizes will allow you to understand where that threshold is.  Again, not sure if this applies to ASDB since they are new and proprietary.