What makes synceddb a good offline-first database?

[sebastianmacias]

I'm in the process of evaluating multiple offline-first databases and I just found out about synceddb. I'm very excited to see other alternatives to gun.js (which I'm currently using and recommending for a few projects).

If you don't mind taking the time to answer a few questions, I would love to know:

• how does synceddb compares to and what are its benefits over gun.js? -- I can already see how being able to use multiple mature db backends such as PostgreSQL to persist the data could be a huge plus.
• can you query the data even if the server is offline?
• how about inserts and updates when the server is offline?, how would they synchronize later on and how are conflicts handled?
• when you run a conditional query in the client does it execute on the server or on the client?
• do you have any non-scientific benchmarks for the client and server side?
• what level of concurrency can synceddb handle? how much data can it handle offline in the client?
• any other highlights or benefits?
• what are its current limitations?

Thanks for all the good work so far and also thanks in advance for taking the time to answering these questions. I'm planning to run a few test in the next weeks.

[nevf]

@sebastianmacias I am not using synceddb or gun.js however this topic is also of great interest to me.

I have been keeping an eye on Gun for a while and I struggle with it being called a "database". AFAIK it does not use indexes, has no query language capabilities, is primarily in-memory and it's replication has been questioned (search Redit). Also when I tried it offline, synchronization failed when it went back online. There is an old Github issue on this, which I think still hasn't been addressed.

To me Gun.js is more like an in memory mesh/graph with replication capabilities.

You might want to look at https://www.npmjs.com/package/dexie-syncable which is where I think I'll head as I already use Dexie.js in my Web app Clibu.

If you you are planning on writing up your evaluation I'd certainly be interested in seeing that.

[paldepind]

I'm not familiar with Gun.js.

One of the distinguishing features of SyncedDB is that it attempts to be a very lightweight wrapper around IndexedDB. It's essentially IndexedDB + migrations + promises + syncing.

can you query the data even if the server is offline?

how about inserts and updates when the server is offline?

Everything happens offline first. Queries, inserts, updates, etc. Afterwards, if there is a connection to the backend, does the syncing happen.

how would they synchronize later on and how are conflicts handled?

Conflicts are handled by invoking a user-supplied callback. This callback can be used to implement the conflict handling that is appropriate for the application. An example of this can be found in the counters example.

[nevf]

@paldepind Thanks for replying to @sebastianmacias

A few issues I personally see with Synceddb:

• It only supports very basic queries, and if I'm right queries are only in indexed properties.
• It doesn't appear to support indexes on array items. For example I have an array of documents inside a document and I want to index those.

Dexie.js handles both of these cases.

[sebastianmacias]

Thanks @nevf and @paldepind for your feedback. Dexie.js Iooks interesting as well. I plan to implement a basic app with gun.js, synceddb and Dexie.js and will publish what I find along with the source code.

[amark]

@paldepind nice work! :) Keep it up. We need more people create better databases.

Wanted to reply to @nevf 's concerns:

• You can index anything anywhere in gun, this is because all nodes in a graph are already stored at a top level index - if you have that key, the lookup is O(1).

• You are correct, the query language is its own graph traversal system - it is powerful enough that we've implemented prototypes of SQL and Mango and other query languages on top, but those won't be official till later.

• Yes, you are correct, it is primarily in-memory. However gun-flint adapter has plugins for MySQL, MongoDB, and others.

• If reddit is your basis for proving something is "correct" or not, then I can't help you, I replied to them with resources, facts, links, automated tests (that check split-brain failures, and various CAP tradeoffs), and more. The only thing they replied with was "hahaha javascript hahahaha" (which no doubt, JS is a dangerous language for DBs) but was totally dismissive of the evidence.

• Re-sync happens based on what data you are subscribed to, so offline edits may not have synced if the data wasn't subscribed. I'd appreciate it if you could dig up the github issue for me too, just in case.

[nevf]

@amark Thanks for taking the time to respond.

The Github issue is https://github.com/amark/gun/issues/259 which dates back to Nov 1, 2016 and is still open. The initial post is from PsychoLlama, however I reported this and he raised the issue.

For my use case storing all data in memory won't work because it can get big and would waist resources. I also need composite indexes and multiple indexes on a document (JSON Data) which is all doable with IndexedDB and MongoDB etc.

I have recently looked at the Gun docs and it is good see information on Conflict Resolution etc. I don't think that existed at the time of the Reddit thread.

[Jaikant]

@sebastianmacias can you share your findings between these wonderful options made by these fantastic ppl 💯 How much of an issue is #22 ?

[sebastianmacias]

Hi @Jaikant sure, these are my non scientific thoughts about about the libraries:

Gun.js

Pros:

• First class offline support, does a great job at syncing data with remote sources
• Local and remote data can be encrypted

Cons:

• Limited query engine
• No support for join queries nor aggregate queries

Dexie.js

Pros:

• Flexible query engine
• Can sync with remote sources

Cons:

• Limited support for relationships and no support of join nor agregate queries

Lovefield

Pros:

• Amazing performance
• Excellent query engine, supports relationships, join and aggregate queries
• Can be used with local sources (IndexedDB) or remote (Firebase) but no other remote adapters are available

Cons:

• No remote sync, it can use either a local or a remote adapter
• Even though it's used at Gmail I was recently told by its main maintainer that the project is in maintenance mode and that it is very unlikely that Google will be adding new features (maybe so it doesn't compete with Firebase?)

Nano-SQL

Pros:

• Great query engine with support for relationships, join queries and offers ways to handle aggregate queries and functions
• Allows listening to data changes events
• Multiple adapters for browser and server-side persistence

Cons:

• No remote sync yet but looks like there is interest and will be implemented