The motivation behind implementing our own lock is to not depend on any
dependency as we should moving forward. This is a experiment for now as
a single test obviously is not enough but I believe this is the right
direction to on.
## benchmark tldr;
Execute benchmarks have a performance improvement around [1.78%, 7.5%]
which seems like it went okay as it was expected from removing
`pthread_mutex` calls.
## benchmarks before
```
Prepare `SELECT 1`/Limbo/SELECT 1
time: [575.63 ns 577.33 ns 580.07 ns]
change: [-1.3304% -0.8881% -0.4675%] (p = 0.00 < 0.05)
Change within noise threshold.
Prepare `SELECT * FROM users LIMIT 1`/Limbo/SELECT * FROM users LIMIT 1
time: [1.2070 µs 1.2114 µs 1.2166 µs]
change: [-0.8670% -0.4084% -0.0252%] (p = 0.06 > 0.05)
No change in performance detected.
Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou...
time: [2.9845 µs 2.9895 µs 2.9951 µs]
change: [-3.0470% -2.6038% -2.1301%] (p = 0.00 < 0.05)
Performance has improved.
Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou... #2
time: [1.6015 µs 1.6084 µs 1.6157 µs]
change: [-0.0676% +0.3850% +0.8704%] (p = 0.11 > 0.05)
No change in performance detected.
Execute `SELECT * FROM users LIMIT ?`/Limbo/1
time: [442.46 ns 446.72 ns 454.13 ns]
change: [+3.9744% +4.5337% +5.3357%] (p = 0.00 < 0.05)
Performance has regressed.
Execute `SELECT * FROM users LIMIT ?`/Limbo/10
time: [3.1722 µs 3.1850 µs 3.1980 µs]
change: [+7.1994% +7.7452% +8.2856%] (p = 0.00 < 0.05)
Performance has regressed.
Execute `SELECT * FROM users LIMIT ?`/Limbo/50
time: [14.976 µs 15.024 µs 15.078 µs]
change: [+5.7879% +6.2419% +6.7139%] (p = 0.00 < 0.05)
Performance has regressed.
Execute `SELECT * FROM users LIMIT ?`/Limbo/100
time: [29.834 µs 29.925 µs 30.024 µs]
change: [+4.6519% +5.0384% +5.4491%] (p = 0.00 < 0.05)
Performance has regressed.
Execute `SELECT 1`/Limbo
time: [45.135 ns 45.439 ns 45.763 ns]
change: [-0.4703% -0.0496% +0.3622%] (p = 0.81 > 0.05)
No change in performance detected.
```
## benchmarks after
```
Prepare `SELECT 1`/Limbo/SELECT 1
time: [585.61 ns 590.92 ns 596.49 ns]
change: [+0.5902% +1.1505% +1.7012%] (p = 0.00 < 0.05)
Change within noise threshold.
Prepare `SELECT * FROM users LIMIT 1`/Limbo/SELECT * FROM users LIMIT 1
time: [1.2061 µs 1.2090 µs 1.2119 µs]
change: [-0.2364% +0.0977% +0.4252%] (p = 0.57 > 0.05)
No change in performance detected.
Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou...
time: [2.9854 µs 2.9893 µs 2.9936 µs]
change: [-0.5752% -0.2529% +0.0167%] (p = 0.09 > 0.05)
No change in performance detected.
Prepare `SELECT first_name, count(1) FROM users GROUP BY first_name HAVING count(1) > 1 ORDER BY cou... #2
time: [1.5853 µs 1.5983 µs 1.6108 µs]
change: [-2.3810% -1.7986% -1.2748%] (p = 0.00 < 0.05)
Performance has improved.
Execute `SELECT * FROM users LIMIT ?`/Limbo/1
time: [429.84 ns 431.34 ns 433.07 ns]
change: [-2.7721% -1.8504% -0.8738%] (p = 0.00 < 0.05)
Change within noise threshold.
Execute `SELECT * FROM users LIMIT ?`/Limbo/10
time: [2.9184 µs 2.9254 µs 2.9323 µs]
change: [-8.2377% -7.7816% -7.3373%] (p = 0.00 < 0.05)
Performance has improved.
Execute `SELECT * FROM users LIMIT ?`/Limbo/50
time: [14.190 µs 14.229 µs 14.271 µs]
change: [-6.2034% -5.7858% -5.3552%] (p = 0.00 < 0.05)
Performance has improved.
Execute `SELECT * FROM users LIMIT ?`/Limbo/100
time: [28.734 µs 28.856 µs 28.979 µs]
change: [-4.3640% -3.9462% -3.5492%] (p = 0.00 < 0.05)
Performance has improved.
Execute `SELECT 1`/Limbo
time: [43.144 ns 43.237 ns 43.326 ns]
change: [-4.9417% -4.5554% -4.2030%] (p = 0.00 < 0.05)
Performance has improved.
```
Closes #1120
Project Limbo
Limbo is a project to build the modern evolution of SQLite.
Features and Roadmap
Limbo is a work-in-progress, in-process OLTP database engine library written in Rust that has:
- Asynchronous I/O support on Linux with
io_uring - SQLite compatibility [doc] for SQL dialect, file formats, and the C API
- Language bindings for JavaScript/WebAssembly, Rust, Go, Python, and Java
- OS support for Linux, macOS, and Windows
In the future, we will be also working on:
- Integrated vector search for embeddings and vector similarity.
BEGIN CONCURRENTfor improved write throughput.- Improved schema management including better
ALTERsupport and strict column types by default.
Getting Started
💻 Command Line
You can install the latest `limbo` release with:
curl --proto '=https' --tlsv1.2 -LsSf \
https://github.com/tursodatabase/limbo/releases/latest/download/limbo_cli-installer.sh | sh
Then launch the shell to execute SQL statements:
Limbo
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database
limbo> CREATE TABLE users (id INT PRIMARY KEY, username TEXT);
limbo> INSERT INTO users VALUES (1, 'alice');
limbo> INSERT INTO users VALUES (2, 'bob');
limbo> SELECT * FROM users;
1|alice
2|bob
You can also build and run the latest development version with:
cargo run
✨ JavaScript
npm i limbo-wasm
Example usage:
import { Database } from 'limbo-wasm';
const db = new Database('sqlite.db');
const stmt = db.prepare('SELECT * FROM users');
const users = stmt.all();
console.log(users);
🐍 Python
pip install pylimbo
Example usage:
import limbo
con = limbo.connect("sqlite.db")
cur = con.cursor()
res = cur.execute("SELECT * FROM users")
print(res.fetchone())
🐹 Go
- Clone the repository
- Build the library and set your LD_LIBRARY_PATH to include limbo's target directory
cargo build --package limbo-go
export LD_LIBRARY_PATH=/path/to/limbo/target/debug:$LD_LIBRARY_PATH
- Use the driver
go get github.com/tursodatabase/limbo
go install github.com/tursodatabase/limbo
Example usage:
import (
"database/sql"
_"github.com/tursodatabase/limbo"
)
conn, _ = sql.Open("sqlite3", "sqlite.db")
defer conn.Close()
stmt, _ := conn.Prepare("select * from users")
defer stmt.Close()
rows, _ = stmt.Query()
for rows.Next() {
var id int
var username string
_ := rows.Scan(&id, &username)
fmt.Printf("User: ID: %d, Username: %s\n", id, username)
}
☕️ Java
We integrated Limbo into JDBC. For detailed instructions on how to use Limbo with java, please refer to the README.md under bindings/java.
Contributing
We'd love to have you contribute to Limbo! Please check out the contribution guide to get started.
FAQ
How is Limbo different from Turso's libSQL?
Limbo is a project to build the modern evolution of SQLite in Rust, with a strong open contribution focus and features like native async support, vector search, and more. The libSQL project is also an attempt to evolve SQLite in a similar direction, but through a fork rather than a rewrite.
Rewriting SQLite in Rust started as an unassuming experiment, and due to its incredible success, replaces libSQL as our intended direction. At this point, libSQL is production ready, Limbo is not - although it is evolving rapidly. As the project start to near production readiness, we plan to rename it to just "Turso". More details here.
Publications
- Pekka Enberg, Sasu Tarkoma, Jon Crowcroft Ashwin Rao (2024). Serverless Runtime / Database Co-Design With Asynchronous I/O. In EdgeSys ‘24. [PDF]
- Pekka Enberg, Sasu Tarkoma, and Ashwin Rao (2023). Towards Database and Serverless Runtime Co-Design. In CoNEXT-SW ’23. [PDF] [Slides]
License
This project is licensed under the MIT license.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in Limbo by you, shall be licensed as MIT, without any additional terms or conditions.
