I would not want to tie my projects to that API. What I would like to see on top of IndexDB is an SQL database.
So you can run SQL queries on the client against your IndexDB storage. SQL is such an awesome language to work with data. No matter which frameworks, languages or libraries become popular or go out of fashion, I am sure I will maintain my SQL queries for decades.
...that synchronizes with a server-side abstraction layer on top of MongoDB. This is essentially the Meteor architecture.
Synchronization is non-trivial and the storage abstraction options come down to NoSQL JSON document stores, GraphQL, and SQL. Browsers support IndexedDB while native iOS/Android support SQLite. I’m not aware of any decent solution that synchronizes a relational database with client-side SQLite.
I too would prefer a SQLite Sync solution that just works and SQLite in the browser available from Service Workers but it is what it is.
Syncing to a server is another issue and I am not sure if it should be part of the same library.
It's not so great for schemaless object databases or navigating nested arrays and hashmaps.
Some relational databases can store JSON objects, and incorporate SQL extensions to navigate those objects.
But in general, SQL doesn't seem to be a great tool for data that isn't a collection of two-dimensional data structures.
Then we put sql on top of data lakes with things like big query, spark structured streaming, Athena etc.
Then we put sql on top of streaming systems like kafka with ksqldb.
And on top of search engines etc etc...
He's not wrong... Sql is easy, easy is good.