Support libSQL adapter

[TzviPM]

Environment

Knex version: N/A
Database + version: libsql
OS: N/A

Feature discussion / request

1. Explain what is your use case

I would like to use libSQL (https://github.com/tursodatabase/libsql) as an adapter. Locally, I will use a sqlite file, and then, in production, I will use something like Turso.

3. Explain what kind of feature would support this

Adding a new adapter for libsql or adding infrastructure to support 3rd party adapters (If that exiosts already, please kindly point me to the docs or an example :) )

5. Give some API proposal, how the feature should work

Similarly to better-sqlite3, simple define libsql as the adapter.

I would love to contribute to the poject either by:

1. Building a libsql adapter and creating a PR to contribute it back to knex
2. Helping to act as a tester for an API that allows 3rd party adapters.

[rluvaton]

Custom dialects are supported

See this for example:

https://github.com/Tomas2D/knex-firebird-dialect

We should better document it though, a PR for that welcome

[TzviPM]

One thing I'm noticing so far is that there are documentation-esque comments in the code that are not doc comments. For example, in client.js:

// The base client provides the general structure
// for a dialect specific client object.

class Client extends EventEmitter {

Also, I'm wondering how it will work to build a dialect in pure typescript. There are type definitions for the external APIs, but not for the client code, AFAICT. Turns out there are type definitions for the Client API 👍🏼

[ruohki]

There is a client from the turso guys

https://github.com/libsql/knex-libsql

[kibertoad]

@TzviPM We would accept a new dialect if you send a PR with tests

[ruohki]

This is basically just using the @libsql/sqlite3 library under the hood

[rxlxnd]

would appreciate this, since it mean that other tools relying on knex would be able to natively offer libsql support

[mercmobily]

Thanks for your interest in adding libSQL support to Knex! This is a great suggestion, especially given the growing popularity of Turso and edge databases.

Good News: Multiple Paths Forward

1. Third-Party Adapter Already Exists
   The Turso team has created knex-libsql: https://github.com/libsql/knex-libsql

   You can use it today:

   npm install @libsql/knex-libsql

   This adapter uses @libsql/sqlite3 under the hood and provides compatibility with Knex's API.

2. Custom Dialects Are Supported
   Knex already supports custom dialects! You can create your own without modifying Knex core. Check out this example: https://github.com/Tomas2D/knex-firebird-dialect

   The pattern is to extend the base Client class and implement the necessary methods for your database.

3. We'd Accept a PR for Native Support
   As @kibertoad mentioned, we'd be happy to accept a PR that adds libSQL as a built-in dialect, provided it includes comprehensive tests. This would make libSQL a first-class citizen in Knex.

Benefits of Native Support

Having libSQL as a built-in dialect would:

• Enable tools that depend on Knex to automatically offer libSQL support
• Provide better TypeScript integration
• Ensure compatibility with future Knex versions
• Reduce dependency management for users

If You Want to Contribute

To add libSQL as a native dialect:

1. Create a new dialect folder under /lib/dialects/libsql/
2. Extend the SQLite3 dialect (since libSQL is SQLite-compatible)
3. Override methods specific to libSQL's features (like remote connections)
4. Add comprehensive tests following our existing pattern
5. Update TypeScript definitions

The implementation would likely be similar to how better-sqlite3 extends the base SQLite dialect, since libSQL maintains SQLite compatibility while adding network capabilities.

Current Recommendation

For immediate use, I'd recommend using the knex-libsql adapter. It's maintained by the Turso team and works well. If you want to contribute to making it a built-in dialect, that would be fantastic - you could potentially work with the Turso team to upstream their implementation.

We agree that better documentation for custom dialects would be helpful. If you'd like to contribute documentation based on your experience creating a dialect, that would also be very welcome!

I am closing this issue since there is already an adapter, and original poster will submit a PR as indicated.