The Wayback Machine - https://web.archive.org/web/20210124105416/https://github.com/sql-js/sql.js/issues/350
Skip to content

/ sql.js

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

advantages of using SQLjs over SQLite native in NodeJS #350

Open
daonsh opened this issue Feb 25, 2020 · 6 comments
Open

advantages of using SQLjs over SQLite native in NodeJS #350

daonsh opened this issue Feb 25, 2020 · 6 comments
Labels
question

Comments

@daonsh
Copy link

@daonsh daonsh commented Feb 25, 2020

Hi,

Thanks for this project, it's very useful.
I see in the homepage of SQLjs that it's recommended to use SQLite native if using server-side NodeJS code.
However there is an example of using SQLjs with NodeJS.

Comparing the two options, I see several advantages to using SQLjs with NodeJS:

  1. Same database interface, if needing both server-side and client-side database
  2. Easier to test and migrate: can first develop all client-side code and easily move database to server for production uses.
  3. It's easier and faster to use in-memory database with SQLjs. SQLjs can load the database file directly into memory. With SQLite native what I see is that it's possible to make only an empty in-memory database and populate it with SQL commands (which will take time to run).

The only downside I see is that Emscripten code is usually at 50-60% of the performance of native code. So SQLjs is slower (how much?).

Is my reasoning correct?
Especially regarding point #3 - I couldn't find a viable solution to load the file into memory with SQLite native (fast), while SQLjs can easily do this.

Thanks
@kaizhu256
Copy link
Member

@kaizhu256 kaizhu256 commented Feb 25, 2020

long-term i agree sql.js should be used instead of native in nodejs. however,

  1. webassembly is still experimental and hidden behind a flag in nodejs (making it unsuitable for production use). this hopefully will go away in 2 years with node v14.

  2. also, there's no way to incrementally persist a 1gb database in sql.js (you have to rewrite the entire blob to local filesystem everytime you update it). the webassembly-group will need to come up with new filesystem api's to overcome this limitation.
@lovasoa lovasoa added the question label Mar 4, 2020
@AnandarajT
Copy link

@AnandarajT AnandarajT commented Jul 25, 2020

Performance wise which is better?

sql.js takes long time for me. Maybe I am missing something
@lovasoa
Copy link
Member

@lovasoa lovasoa commented Jul 25, 2020

Using the native sqlite is faster and lighter.
@rishabbhattacharyya
Copy link

@rishabbhattacharyya rishabbhattacharyya commented Sep 17, 2020

what's the maximum storage limitation of sql.js?
@kaizhu256
Copy link
Member

@kaizhu256 kaizhu256 commented Sep 17, 2020

depends on browser. for chrome it appears to be 4gb (https://v8.dev/blog/4gb-wasm-memory). My experience however, is chrome-browser (windows 10) starts to freeze and crash when working with datasets over 1gb.
@elmpp
Copy link

@elmpp elmpp commented Sep 17, 2020 •
edited

Any reason why sql.js wouldn't be suitable for use with an ORM? (I'm using the sqlite support in typeorm). Would it be unrealistic to expect to expect the adapter to work with sql.js also?

E2A - i see comments here but perhaps he's mistaken
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
@kaizhu256 @lovasoa @elmpp @daonsh @AnandarajT @rishabbhattacharyya