Introducing new AppSheet database feature in public preview

[ShirleyN]

Please see updated GA announcement --> here

Hi everyone! 

Over the past year, we’ve been conducting user research with app creators, end users and some of you to better understand the app creation experience. Through this research we’ve uncovered challenges with the existing external data sources and noticed a gap in datastore options for citizen developers. With Sheets being the most common connected source for AppSheet apps, we noticed frustrations around:

• Formatting a spreadsheet for app creation can be time consuming
• Changes to the data schema after initial app creation are challenging and can easily break apps
• Unstructured data leaves room for human error in data entry 
• Scalability and sync speed starts to deteriorate as Sheet size increases 

With these challenges in mind, we set out to build a native database for citizen developers to easily and securely manage their data. We believe this will also improve the experience for app creators. 

Today, I’m happy to announce the release of the new AppSheet database feature for public preview! During public preview, access to AppSheet databases is enabled by default for everyone but it will not affect existing apps unless you explicitly add a blank table or connect an AppSheet database inside the AppSheet editor. Use of this public preview feature will be free to everyone but limited to 10k rows per table and 20 tables per database. Note that these limits will change for our public launch. 

To get started, you can create a blank database from the My Apps page. If you’d like to start building an app from scratch, there is also a new Blank app option. This blank app will create a new AppSheet database to use as the data source. 

Within the database editor, you can set the same column types as in the AppSheet app editor for your data. 

After that, you can create an app directly  from the database. This will create an app on the current table only. If you have references to other  tables, you will need to add them using the AppSheet app editor. This is something we’re working on improving. 

Since this feature is in public preview, we’re still making improvements to it and appreciate your patience with issues you may face. Some features that are coming include a smoother import/export of data, database recovery, and email notifications after sharing a database. 

We will also be updating our support documentation to include this new feature. For those who would like to disable access to this feature, see the Disable AppSheet databases policy. 

Thank you and happy app building, 

Shirley

Dec 8 Update: Sheets import is now enabled on the My Apps page! More details on import and other ways to create a database here.

Feb 1 Update: Column types set inside the editor were getting reset every users regenerated schema twice. This has been fixed.

Feb 14 Update:  Virtual columns can now be set as labels inside the AppSheet app editor.

Apr 26 Update:  Deleted tables can now be restored through the new history experience inside the database. Please see support article here.

May 3 Update: You can now share a database with an entire AppSheet team as a shared datasource. AppSheet teams are only available to AppSheet enterprise users. 

May 24 Update: Audit logs for AppSheet databases are now available for admins and database editors. You can also restore deleted databases. More info here. 

[kvngo94]

Hey guys, 

Should we use the Row ID (built-in) as Key 

Or should we create another column for the Key with the initial formula to create the Unique Key : 

text( now(), "yyyyMMddHHmmss" ) ?

Hope you can share your idea

[dbaum]

Why would you bother creating a different arbitrary key? The only reason not to use the Row ID would be if you happen to have a natural key that's easier to reference or if you need to be able to infer a row's key from values available in other contexts.

[SkrOYC]

---

@dbaum wrote:

if you happen to have a natural key that's easier to reference or if you need to be able to infer a row's key from values available in other contexts

---

💯

[SkrOYC]

---

@kvngo94 wrote:

text( now(), "yyyyMMddHHmmss" )

---

That's a really bad key unless you don't do any loop

[Nick_Haschka]

Any updates on the full release timeline? I’d love to move some of my operational databases in sheets to AppSheet Databases ASAP.

[Nick_Haschka]

@ShirleyN - any updates on when to expect public launch?

[StephenHind]

@ShirleyN @zito  I've just heard that the AppSheet Databases are a replacement for the Area 120 Tables: can you confirm this to be the case?

I never got chance to try Tables as I'm in the UK, but is this a "backwards compatible" change?  i.e. will those who use Tables get moved to AppSheet databases and they will continue to work?  Will the Apps Script Tables Service work with AppSheet databases?

I'm sure those who actually use tables will have many more questions.

[zito]

Hey Stephen,

Nice to hear from you - we chatted once or twice a million years ago when I was working inside of Workspace about Google Sites, happy to see you're looking at AppSheet.

To answer your question, AppSheet Database is based on Tables, especially from a UX perspective, but is not a 1:1 replacement for Tables.  ASDB's primary use case is to provide a high-performance native data store for AppSheet apps as well as a simplified data modeling interface compared to a traditional database.  

We're focused on getting ASDB to GA right now, rather than trying to duplicate all of the Tables features to ASDB.  Once we get to GA, we'll be assessing what makes sense to bring over and how - since AppSheet already has support for things like automation and Apps Script, we might want to reimagine how some of the Tables-comparable features might be implemented.  

[StephenHind]

@zito  it's good to hear from you again!  We've developed a few apps for both ourselves internally and externally for clients, it's a great product.  Another Googler suggested that ASDBs were a direct replacement, but it doesn't sound like we're ther eyet.

[Alan_Thorp]

Like it so far, but why, oh why, did date time end up as AM/PM and not 24 hour???

[UPJoinville]

Hello, is there any ETA on fixing the issue with Latlong fields? They are saved on the database without the dots, which breaks the coordinates.

[ShirleyN]

@UPJoinville Thanks for raising this, however, I'm unable to repro the issue. Are you adding data through a connected app or in the database directly? 

[UPJoinville]

I'm doing it using an App. If I directly edit it on the database, it holds the coordinates correctly(eg -26.276885447300163, -48.83444505302993), however if I edit them in the app, it saves them as "-26276885447300163, -4883444505302993", which breaks it.

Btw, as you can guess by now, its eating the dots, not the commas, my bad.

Example 1 - after I manually fixed the coordinates in the database:

 

Local is showing the correct location on the map due to correct coordinate formating.

Example 2 - if I try to edit that record, thats how it pulls the "New column" field(its a latlong field with the bugged coordinate formatting):

Note how its correctly showing the coordinates I manually fixed.

Example 3 - after I use the pin to update the coordinates on the "New Column" field and save, thats how they are saved on the database:

Note how the "Local" field is still ok, since I didnt touch it before saving.

Example 4 - after updating the "Local" field, thats how it is saved on the database:

[mustafa1]

We need to migrate our Google Sheets-based Apps to the Appsheet database. But limits are not enough. Is it possible to test with larger values?
  

[dbaum]

There is a problem when changing the data type of a table's label column.

I had a table with no rows and a single column, whose data type was Text and, of course, was the table's label column. I copied the table to create a new table. I changed the column's name and saved the change. I tried to change the column's data type to Date, but received an error that I could not do so until another column was designated as the label column. I created a dummy Text column and designated it as the label column. I then successfully changed the original column's data type to Date, re-designated it as the label column, and deleted the dummy label column.

[bangbet]

Hi, 

when I use maxrow, select, lookup and other similar formulas from table A (mysql) reference to table B (Google Sheet), it works fine. however it doesn't work properly when I reference to table B (Appsheet Database)

Please help, maybe there is a special formula or special settings

[Koichi_Tsuji]

Just tested sharing feature.

I just direct "domain" to share DB for read only. However, currently we are not able to instruct AppSheet Database to share with Domain.  In terms of Appsheet app alone, we can share with domain by saying "xxxx.co.jp" or "yyy.com" to share the app. Why does not allow the same settings to share ?

@ShirleyN 

[ShirleyN]

Hi Koichi, you should be able to share the database with an AppSheet team, similar to a Sheet in the Share dialog. This prevents users from sharing the entire database to various domains.  

[Koichi_Tsuji]

@ShirleyN 　　Thank you for your advice.

I ve overlooked this option perhaps.

Is this one, right?

 

[ShirleyN]

Yes that's right! 

[Ricky_Chua]

Formatting of Date columns in Database does not have the functionality to select the underlying date-format (or to display the preferred date format for that matter).

My Sheets data is formatted in DD-MM-YYYY. Database does not parse my column automatically as Date. When I explicitly parse the column, it will only parse in the format MM-DD-YYYY, hence many cells do not appear post-parsing (eg: 4/12/2023 appears, but 13/12/2023 does not.) I guess I could convert my underlying data to MM-DD-YYYY first before the import, but that is not preferred.