Increase pricing for enterprise plan

[kennyboy]

A simple suggestion. Please increase pricing for enterprise plan in return for super fast synchronising with Postgres and other SQL cloud databases. AppSheet database will not become the next Postgres SQL anytime soon so why not focus more attention on integrations? Look at Airtable after several years it still is a joke for midsize DBs.

I am confident people will pay more to sync faster on tables with 100K - 1m rows held in cloud DBs. I’ll defo pay a lot more than the miserly $20/month. Try a poll on this suggestion to confirm/dismiss my suggestion.

Thank you

[Trevwiller]

Reduce your rows per database. How many users need to see all 100k - 1 mil rows at once. How many rows need to be refernced for an average user in a daily work flow? Reduce to this limit. Create historical and archived rows to limit data transfers. Understand where the to trim and what to trim. Make split apps for users that require more and apps for users that require less.

[kennyboy]

@Trevwiller

How many rows need to be refernced for an average user in a daily work flow?

A database with over 100k ships can be referenced by any user for ‘any’ of the 100k ships. Example, the Stena Immaculate which just collided with Songol in the North Sea is a random occurrence and unpredictable as a sudden interest. Stop telling me how to use the app if you don’t understand my use case. It’s a database, not a scanty reference list.

[Trevwiller]

Best of luck in your journey.

[WillowMobileSys]

@kennyboy

I am confident people will pay more to sync faster on tables with 100K - 1m rows held in cloud DBs.

What kind of performance are you experiencing? Are you differentiating read times from Sync times?

You may want to look at the Performance Profile of your app.

Typically, apps are constructed to use Security Filters to limit the data to only that the user needs to see. Rarely is there ever a need for a user to have 100K rows visible in an app all at once.

For reference … I have several apps with total rows in the several hundred thousand range. With Security Filters, the apps can Sync in under 15 seconds. It does require some work to ensure that Security Filters are getting the best use of filtering on the database side as well as minimizing impacts from inefficient Virtual Column implementations.

If you are having some slowness issues, state your use case in the Community and I’m sure someone can give you pointers to help get better performance.

I hope this helps!!

[kennyboy]

My app is a ships database with appsheet on the frontend for CRUD operations. We update vessels everyday and it can be ‘any’ vessel on the database. If we set security filter, can you tell me what criteria to filter out? Which of the vessels do we ‘not have to see on the app’? Today, we had 2 vessels colliding in the North Sea. We had to scramble to update everything from the ship technical specs to the ownership details etc., with each update synchronising back to the DB and onwards our API. There are over 200 ‘random’ vessels that we could update in 1 day.

A good fix would have been for security filter to accept query along the likes of 'sync only vessels where ‘user entry contains’ ***. But of course it doesn’t work like that. So, we need to see all the records at once on cards and therefore super fast synchronisation.

Why would it be so difficult for AppSheet to charge $100 - $200 per month for clients who want to handle large data with ease? It’s a database and even Grand Daddy MS Access could handle millions of rows with ease.

[WillowMobileSys]

Sounds like a very interesting app!

@kennyboy

Why would it be so difficult for AppSheet to charge $100 - $200 per month for clients who want to handle large data with ease? It’s a database and even Grand Daddy MS Access could handle millions of rows with ease.

Database is not the issue. AppSheet being a mobile cloud based platform, it is not designed to handle large volumes of data at once with speed. There are other factors that contribute to the overall load times - server-side processing, offline mode, Virtual Column usage, expression implementations, connectivity, etc. The database read times are a very small portion of that overall time.

@kennyboy

If we set security filter, can you tell me what criteria to filter out? Which of the vessels do we ‘not have to see on the app’?

I understand. I still think AppSheet might be able to serve your needs better as is…if Sync times under 20 seconds are acceptable - I’m being conservative.

The way I would handle this is to provide a very lightweight table with just enough details to identify the ships. Users search and select which ships they need to work with, Sync and then the app uses the Security Filters to pull in all related data only for those selected ships. When other ships are required, check those additional rows and re-Sync to load their data. Ships no longer needed for viewing are unchecked to help keep app performance down. This approach would be far, far faster than attempting to load all ship data.

[Suvrutt_Gurjar]

@WillowMobileSys

The way I would handle this is to provide a very lightweight table with just enough details to identify the ships. Users search and select which ships they need to work with, Sync and then the app uses the Security Filters to pull in all related data only for those selected ships. When other ships are required, check those additional rows and re-Sync to load their data. Ships no longer needed for viewing are unchecked to help keep app performance down. This approach would be far, far faster than attempting to load all ship data.

I think @WillowMobileSys has suggested a very apt approach. Just to add or rather expand on his suggestion, you could use Usersettings to facilitate users to load just the enough records in the app for their ongoing requirement. By using usersettings, I believe your following requirement is addressed.

@kennyboy

A good fix would have been for security filter to accept query along the likes of 'sync only vessels where ‘user entry contains’ ***

The following approach may or may not be exactly suitable to you but I believe it can certainly give you some relevant ideas on the judicious use of security filters and that too at the hands of users.

Advanced techniques: Horizontal scaling - AppSheet Help

[Trevwiller]

Reaching back out on this I just read the news on this I dont know the need for your app correct, but the help can be given.

I believe the best use case for your app can be the user settings menu. Using idetifiers or classes of ships if they are kept in your structure. Using a usersetting set up as an enum list. Select the classes of ship you care to look at in any given point. With user settings this happens outside of a sync so can be changed in any given situation.

You will need to set up the security filters in your tables lets call the table SHIPS

Table SHIPS should have a security filter that would be IN([Key Column], [_THISUSER].[Class EnumList]). All child tables of these should have their security filters IN([Parent Table SHIPS Ref], SHIPS[Key])

These will help reduce the amount of rows pulled and help with your sync times. It will also require a learning curve for the users as to understand that they will not be able to see the items if they are not in the usersetting column.

Building more indepth security filters can help further with this. As if there is a time where you do not need to see voyage logs or crew (examples of possible data kept) the user can enable or disable these via a Yes/No usersettings column to prevent the records from pullling in a sync.

Now if the task of naviagting back to the user settings menu becomes a task you can also make an action present on all views as a primary to be a link to view. Your formula will be LINKTOVIEW(“Settings”)

IF this is still a lengthy proccess for syncing you can set up a duel app setup where the first app is to Interact with the table you will create called User Selections like a usersettings style use case. It will need to have a row set up for each individual user know to access the app to prevent cross filtering issues. IF this list is known we can can build this. It will require more effort, but can work out in the end. The first app is your access point. Make each row that is your per user selections contain the users email. Then we will apply a security filter to only grab this users row. The user will make their selections then click save. Once the user clicks save the form view on save action will be link to another app. The app it will go to is the app containing your database data.

We will then link the now made user selections table to the second app. This table will have a security filter to only allow rows where [User Email Column] = USEREMAIL() . Then set up the security filter for the SHIPS table based on these selections. We will also need to see this view in the second app as to continue filtering as needed and the save on form view will need to include a sync now action to provide a reset to the filter options.

This will require more indepth searching into the appsheets comunity for a few quality techniques on doing this elegantly.

I hope this can help.
Google Documentation on USERSETTINGS() -

https://support.google.com/appsheet/answer/10108291?hl=en&sjid=12237341212918242704-NC

[kennyboy]

Guys, thanks. I appreciate everyone’s input. It’s a ball ache it seems and I know there are other CRUD apps optimised for Postgres. I have used AppSheet a long time with Google Sheets and felt this would be ideal but clearly wrong. Anyway, someone told me about Forest Admin and I will be looking into that as soon as possible.

[kennyboy]

Just want to say I will keep you all posted as I have got some clues from your suggestions. In one last attempt, I’ll create a new table in a local AppSheet database and name it [RecentShipUpdates]. This would be one of the tables linked in my main app and would have 3 columns {‘IMONumber’ - 7 digits, ‘VesselName’ - text, ‘LastUpdated’ - date(today())}.

This table will be linked to a Form [SearchVessel] which can be housed in a Dashboard with the other existing views. When user enters a vessel name or IMO number on the [SearchVessel] form, it stores the data in [RecentShipUpdates] table with the ‘LastUpdated’ field auto computed as current date.

On the main table which is from our sql DB, I’ll add security setting as follows;

AND ( OR ( IMONumber in list of [RecentShipUpdates].[IMONumber], VesselName in list of [RecentShipUpdates].[VesselName] ), [RecentShipUpdates].[LastUpdated] >= Date(Today()) - 5 ).

This would ensure that not more than 5 days of recent updates is synchronised at any given time. I might also create an action to delete from [RecentShipUpdates] where [LastUpdated] is more than 5 days old.

Fingers crossed this works and I’ll feedback in a couple of days.