Comparisons

[heri16]

How does this library compare with Alasql?

How about comparisons with lovefield?

[only-cliches]

I use to have a comparison table in the ReadME, might put that back soon. 😄

Here's a copy of that table, updated to the newest version.

	nanoSQL	Redux	TaffyDB	Immutable	LokiJS	NeDB	LoveField	PouchDB	alaSQL	SQL.js
Events	✓	✓	✓	✕	✓	✕	✓	✓	✕	✕
Typescript	✓	✓	✕	✓	✓	✓	✓	✓	✕	✓
Undo/Redo	✓	✕	✕	✕	✕	✕	✕	✕	✕	✕
ORM	✓	✕	✕	✕	✕	✕	✕	✕	✕	✕
RDBMS	✓	✕	✓	✕	✓	✓	✓	✓	✓	✓
IndexedDB	✓	✕	✕	✕	✓	✕	✓	✓	✓	✕
Node	✓	✓	✓	✓	✓	✓	✕	✓	✓	✓
Size (kb)	30	2	5	16	19	27	40	46	88	500

Last time I dug into all these libs (which was quite a few months ago at this point) here's kind of how I think about Lovefield and AlaSQL compared to NanoSQL:

Lovefield Decent client side database. It's quite a bit larger than nanoSQL but doesn't have any way to plug in custom database storage adapters, you're stuck with IndexedDB or nothing. This also means it's not isomorphic, you can't run it in NodeJS. Personally I'm not a big fan of the API either, I think it's unnecessarily obtuse and clunky. The query language is also pretty limited compared to nanoSQL, you can't do query functions for example.

AlaSQL Basically an attempt to provide the full SQL language spec in a javascript database. I've actually benchmarked nanoSQL against AlaSQL quite a few times. I found that the AlaSQL parser takes quite a bit to convert the SQL string into a query, but once it caches that it's very fast. I seriously considered using this library for my projects before building nanoSQL but ran into a few issues that ultimately killed it for me. First, the bundle size is MASSIVE. The sizes in the table above are gzipped, it's half a freakin megabyte uncompressed, that's insane. Second, there's absolutely no event system (this is partly where it gets its speed from) and lastly there's no way to persist data with it easily (on IndexedDB, LevelDB, etc). I think there's experimental support for localStorage but that's unusable for any reasonably large application thanks to localStorage limitations. Like Lovefield, I also think the query language is a bit obtuse. In javascript having the dot syntax between query operators in nanoSQL has been a huge quality of programmer life improvement for me on the client and server side, especially with Typescript able to intellisense. With nanoSQL if you have Typescript and you've skimmed the docs atleast once it's basically impossible to build a query that doesn't work properly, and I really enjoy that.

Hope you find that helpful!

[only-cliches]

Since there's been no response to this issue for a few days I'm going to close it. Feel free to open it back up if you have further questions.

[heri16]

Thanks for the reply! This has been really informative!

[benoror]

Any thoughts regarding LokiJS ?

[only-cliches]

Yeah, they need to get their site back up or remove the link at the top of the repo. 😛

NanoSQL is pretty unique in the fact that it doesn't store any table data in memory (unless you're using the memory adapter), meaning that nanoSQL is the only javascript database I know of that can hold more data than there is Javascript memory. It means that query results are a bit slower (since the database has to actually get the rows and usually do some kind of deserialization) but memory usage is potentially orders of magnitude less. A good way to check if your javascript database stores everything in memory is if it allows synchronous queries, like this:

// obviously pulling from in memory javascript objects.
const result = someDB.getResults();

Before I get into the ways nanoSQL is better for some use cases, let me say if you need a simple noSQL datastore that you intend to use entirely on the client side with small data sets (less than ~10MB) I'd say LokiJS is a decent choice.

Besides the memory limitation mentioned above, these are a few other things nanoSQL does that LokiJS doesn't:

1. nanoSQL has a plugin system that lets you hook into nearly every query step or database action and change it. I haven't seen a database with a plugin system more powerful than nanoSQL.
2. Secondary indexes are way more flexible and powerful.
3. You can convert data models into typescript files.
4. You can have strong data consistency with data models.
5. nanoSQL has query functions, graph queries, geospatial indexes, far more adapters are supported and there's lots of other SQL style goodies.

[benoror]

@ClickSimply thanks for your thoughtful response!

The prototype I'am working on has the potential to handle 1,000s of records, so this is valuable info to know 😄

Regarding data consistency on point 4, do you mean the ability to ensure validity of foreign-key relationships and have ACID txs?

BTW, right now my main blocker for my use case is this issue, hopefully you can take a look 🙈 : https://github.com/ClickSimply/Nano-SQL/issues/168

[only-cliches]

With point 4, I'm mostly saying that I don't agree with the noSQL idea of schemaless databases, I think it's actually a pretty messy and difficult to maintain way to do things.

nanoSQL allows you to declare what your data model is for each table, then it enforces that data model on inserts to make sure that you always have data types you expect. You can even have the database auto enter default values for you or filter rows before they're updated to make global changes.

Foreign keys are enforced but we don't have ACID transactions in place, mostly because many of the data backends like Redis don't really support ACID transactions and even when they do we can't do ACID transactions across tables most of the time (which is needed for index updates).

For transactions I'm looking at setting up a two phase commit pattern, something that can guarantee an entire transaction is commited entirely or not at all but it's going to have a pretty dramatic performance cost speed wise.

I'll have your issue taken care of soon!