One year ago, we announced a bold project: a fork of SQLite. After noticing that SQLite doesn’t welcome external contributions (Open Source, not Open Contribution), and companies were increasingly trying to build around that fact, we decided it was the best way forward. The libSQL project was born.

Forking such a well established and well-loved project like SQLite is a tall order, but over the past year, we have seen the project grow and get more accepted by the community.

But one year later, we’re bringing libSQL into the Turso family. Read on for the details about what that means, practically, but first let’s recap what libSQL brings to the table:

Better support for ALTER TABLE, a well established SQLite wart.
User-defined Functions in WASM.
Support for streaming write-ahead log changes, to enable replication.
A server mode, making libSQL available over HTTP for use in serverless environments, including a protocol and its drivers.

We have our own self interest in making those changes: we are the creators of Turso, a database that brings SQLite to serverless environments. Some of the changes described above are directly useful to us.

But we also wanted to create a welcoming community, that is open to everybody, abides by a modern code of conduct and a clear OSS license, and reimagined what SQLite could be in broader ways than just our narrow needs.

Because of that, we have made a couple of explicit choices:

We would keep all the identity and code separate from our main organization, as well as the Discord community.
We would keep the server bits that were used for our product separate from the embedded database.
The libSQL project would not refer to Turso.

Our goal was to create an explicitly less corporate environment, but it did come with downsides

Branding

Keeping libSQL on its own separate, unconnected website from Turso and with its own separate branding just meant trying to build two new brands at the same time. It meant twice the investment in everything too, and ended up meaning that libSQL had less exposure than it could have.

Community

For similar reasons, it was hard to invest in community management and distribution. The Turso Discord is way more active than the libSQL Discord, and many people go there to ask questions about libSQL.

Features

The lines between the embedded database and the network database are arbitrary. As an example, we will announce this week a feature called “embedded replicas”, that allows your database to be used both locally and over the network interchangeably, with replication happening between those two. Keeping the server bits separate made the development of this way harder than it should’ve been.

Time for a change.

Given the size of the task we took upon us, to improve on the most used database in the world, we are proud of what we have achieved. This comparative graph for Github stars is telling:

But despite libSQL’s initial success, it is still not big enough for a foundation. We know that by putting more resources into the project, we could do a lot more. So it is time to revisit our decisions and adapt.

First, here is what is not changing: we still welcome contributions from everybody, including competing businesses, and pledge to create an open community.

We are also not changing the license nor have any intention to, and the fact that we don’t require a CLA should make a license change to a more restrictive license impossible (by design).

Starting today, we are announcing the following changes:

Discord

The libSQL Discord server will be discontinued. We invite all of the existing libSQL Discord members to join us on the Turso Discord server, where we now host a dedicated #libSQL channel.

Github organizations

The github.com/libsql/libsql.git repository, containing the embedded fork of SQLite, as well as the server implementation, will be moved to the github.com/tursodatabase organization, making it clearer that this is a project sponsored by Turso.

The embedded fork, libsql.git, is already moved, and the server implementation will be moved soon.

Code organization

We will rename the server implementation from sqld to libsql-server(although the binary may still be called sqld). At a later date, we plan to fold it into the main libsql repository. Users will still be able to build and use only one or only the other, but having them both together will make it easier to build features that seamlessly transition from network to embedded and vice versa.

We look forward to building a bright future for libSQL and a renewed, more unified focus on open source adoption as part of the Turso family.

#Community

We’re bringing libSQL into the Turso family