Best Cloud Database for Appsheet

[Sonny_Aries]

Hi all,

based on your experience, what is best db for Appsheet?

1. MSQL
2. MySql
3. Postgre
4. Redshift
5. other

in term of speed for Appsheet. let say, table that use or record in table is same for all cloud db

thanks

[Lance_Bennett1]

I know it’s simple but Google Sheets has been great for my apps. Updates are fast. No complaints here.

[poutt]

Hi Lance,

As your data grew bigger, have you encountered performance issues with Google Sheets as your database? It is also working well for me but I am concerned Google Sheets is not made to handle bigger amounts of data which might decrease performance down the road.

Thank you,

Pepe

[Swoopy]

Apps would start slumbering when you have 10,000 rows, or much sooner if your app is carrying many expensive expressions like SELECT().

[Swoopy]

Only unless you have tables carrying 50,000+ rows inside your app.

[Swoopy]

I really need to know as well if it's worth upgrading back-end database; let's say for 2 related tables having 200,000 rows each; and using AppSheet as front-end user interface.

So far I've never seen anyone making a comparison video to test or demonstrate AppSheet performance among various back-end databases, even by AppSheet team themselves though this could encourage creators to make decision of upgrading their plan along with upgrading database  engines.

[SkrOYC]

I think that in the end your expressions matter way more than where your data is.
A table with 200 records could take a minute to sync if it depends on heavy expressions while thousands of rows can be read on seconds if that table is optimized

[Swoopy]

That's right but it'd never answer the question.

I believe many ppl need to see how well & how far AppSheet can go if it's working with huge table having hundreds of thousands rows.

Just show us by comparing various clouds using simple app, remove all expensive expressions.

1. Sync speed

2. Search speed

3. Filter speed especially for enum columns

4. Enum dereference speed

5. Calendar view when changing month (in monthly view)

6. etc.

Note that these top 5 items are the most headache of AppSheet handling huge tables (based on my observation).

Will it improve & How much improvement if creators move their data to other famous cloud databases?

[Steve]

The data store has no effect on (2), (3), (4), and (5).

[Swoopy]

Thanks. And now comes to questions:

1. How much (?X) improvement for (1) even when no expensive expressions involve ?

2. On (2), (3), (4), and (5) when experiencing performance issues, no point to upgrade data source (let's say all tweaks are already used and partitioning is not the way to go) ?

Note that we are talking about hundreds of thousans rows tables (or more).

[Steve]

1) There are too many variables to say, or to even suggest. The only way to find out is to do your own testing with your own app.

2) Correct. Once the sync is complete, all the data is on the device and the device uses the data it has there. Note that partitioning also has no effect on (2), (3) (4), and (5).

[Swoopy]

Thanks. And this brings us to a conclusion that AppSheet not designed for working with the mentioned situation, the huge databases in terms of rows.

It's not like client-server apps (or the likes) we're familiar with or had ever seriously expected that loads can be shared on sever side automatically controlling only some portion of data rendering on device nicely (like mobile shopping app architecture).

For the big databases we have 2 choices; tricky using it or not using it.

[PabloDemichelis]

Does anyone know if it is worth using a DB instead of Google Sheet? Or any tips to optimize synchronization?

[SkrOYC]

---

@PabloDemichelis wrote:

any tips to optimize synchronization

---

Praveen - Improving general performance
Praveen - Take on SELECT() performance