Use better-sqlite3

[sushantdhiman]

Thinking about using better-sqlite3 for SQLite database, mainly for supporting 64bit Integers. Their benchmark looks great as well

WiseLibs/better-sqlite3#262

[papb]

Completely agreed!!

[usebaz]

@sushantdhiman Hi, if need help I can make PR with migrate to better-sqlite3

[sushantdhiman]

@usebaz Thanks. Soon master branch will point to the next beta. After that you can submit your PR

[etylermoss]

Is there any update on this?

[sushantdhiman]

@etylermoss Currently no one is working on this. I tried to convert some time ago but found that API is really annoying :)

For example,

1. run, (only on statements that do not return data)
2. get (only on statements that return data)

This mean as an ORM we need to check what kind of query is going to execute (will it return data?) and switch methods based on that. I think this is unnecessary complication.

I wish they could just provide simple method to execute any arbitrary query (with parameters) like every other dialect library in existence.

So officially we want to switch but we are not working on it. If someone want to do a PR for this, we will welcome that change.

[louy2]

How is it handled with node-sqlite3 currently? It has the same run/get split.

[lesion]

@etylermoss Currently no one is working on this. I tried to convert some time ago but found that API is really annoying :)
For example,
1. run, (only on statements that do not return data)

2. [`get`](https://github.com/JoshuaWise/better-sqlite3/blob/master/docs/api.md#getbindparameters---row) `(only on statements that return data)`

This mean as an ORM we need to check what kind of query is going to execute (will it return data?) and switch methods based on that. I think this is unnecessary complication.

I wish they could just provide simple method to execute any arbitrary query (with parameters) like every other dialect library in existence.

So officially we want to switch but we are not working on it. If someone want to do a PR for this, we will welcome that change.

Hi there!
Is your attempt available somewhere? I'm thinking of trying to implement this

[bradisbell]

Not stale.

[John-H-Smith]

Any Updates?

[ephys]

@John-H-Smith we're thinking about doing it for v7 sequelize/meetings#7

[cirosantilli]

I reproduce their 10x faster benchmarks in my project when migrating from better-sqlite3 to sequelize 6, It is amazing!!

Make sure to compile with that log limiting options maxed out if possible to prevent log truncation: WiseLibs/better-sqlite3#306

[tankakatan]

Hi everyone,

Please consider adding support for better-sqlite3 package ASAP. We are experiencing lots of issues with node-sqlite3 when shipping our Node.js app as a packaged executable for different platforms. Even though it is possible to include it in the bundle, our users keep reporting very weird and hard to debug issues with the old lib.

[ephys]

At this moment none of the maintainers are working on replacing sqlite3 with better-sqlite3 and won't be in the foreseeable future since there are many other features that we want to add, and bugs we need to fix. If somebody from the community makes a Pull Request we are of course happy to review that.

[tankakatan]

Thank you very much for the quick response @ephys. In our team we'll estimate the effort needed for the integration, and find out whether we are able to allocate resources for that. Also pinging @usebaz who offered their help with the integration a few years ago. Just in hope they are still available.

[fzn0x]

We may need to take a note about this:

• For the performance reasons: Convince me to use better-sqlite3 WiseLibs/better-sqlite3#262 (comment) (There is a large difference on the benchmark he provide.)

• For the compability reasons: Help me use Electron! WiseLibs/better-sqlite3#126

• There is no official support for type definitions.

• Recent issue with binaries compability support for Node v19.x

• The way to include sqlite extension with better-sqlite3 in Sequelize

[luka2i]

any updates?

[WikiRik]

No updates. We've moved this internally to v8 when we split the various dialects off to separate packages. That way we can even look into supporting multiple connectors for sqlite

[dixiekong]

any updates?

[j-refs]

Is this still not being worked on? If the maintainers approve, I'll gladly open a fork open to the community to get this feature up and running and PR it.

After a quick scan of the source, it doesn't really seem as hard as every is making it, seems like the regular sqlite dialect can be easily modified for better-sqlite3, but I just don't have the time to scan and port everything, maybe if we make it a community effort, we can get this done

[WikiRik]

@j-refs internally this has been postponed to v8 when we split dialects. If you can make it so that users can select which of the two adapters they want to use, we can reconsider adding this to v7.

If you create a fork, please mention it here in this issue as well so we can refer people to it in the meantime

[j-refs]

Will look into forsure. Probably later today, I work nights and I'm ready to KO. Any info the maintainers wanna add in before I form?

[yisar]

any updates?

[j-refs]

Yes sorry, struggling to find time to get started on this, but is definitely on my queue

[j-refs]

I'm ready to start working on this. Would y'all prefer a branched PR or it's own repo?

[ephys]

@j-refs So sorry, I did not see your latest message

The SQLite package has been split to its own package (https://github.com/sequelize/sequelize/tree/main/packages). You can fork the repository, create a new package called better-sqlite3, and open a PR to this repository :)

As we're opting for providing both @sequelize/sqlite3 and @sequelize/better-sqlite3, this won't be a breaking change after all

Note that @sequelize/better-sqlite3 cannot extend @sequelize/sqlite3 directly to avoid installing both sqlite3 and better-sqlite3. Instead, anything that you wish to re-use from @sequelize/sqlite3 should be moved to an internal package, @sequelize/abstract-sqlite