Benjamin-Philip

Turxo - bindings to the Turso database

Announcing Turxo! Turxo is a library (hex, git repo) for bindings to the Turso database, a SQLite compatible in-process database written in Rust. It has a number of new features over SQLite like multi-version concurrency control (MVCC), io_uring backed async I/O, edge replication, vector support and more. Turxo is the first step towards bringing these improvements to the Elixir ecosystem.

As of now we support the following operations:

Open or create a Turso database, including in-memory databases
Connect to an open database
Execute SQL commands or perform queries on a connection
Prepare reusable SQL statements, then execute or query them

Here’s a rough example copied from the README:

alias Turxo.NIF.Wrapped, as: Turso

# Open an in-memory database
{:ok, db} = Turso.db_open(":memory:")

# Establish a connection
{:ok, conn} = Turso.db_connect(db)

# Execute SQL (no parameters)
{:ok, 0} =
  Turso.conn_execute(
    conn,
    "CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, email TEXT)",
    []
  )

# Insert using positional parameters
{:ok, 1} =
  Turso.conn_execute(conn, "INSERT INTO users (name, email) VALUES (?1, ?2)", [
    "alice",
    "alice@example.com"
  ])

# Query with positional parameters
{:ok, [["alice@example.com"]]} =
  Turso.conn_query(conn, "SELECT email FROM users WHERE name = (?1)", ["alice"])

# Prepare a statement
{:ok, stmt} =
  Turso.conn_prepare(conn, "INSERT INTO users (name, email) VALUES (:name, :email)", false)

# Execute the prepared statement with named parameters
{:ok, 1} = Turso.stmt_execute(stmt, name: "bob", email: "bob@example.com")

# Query with named parameters
{:ok, [["bob@example.com"]]} =
  Turso.conn_query(conn, "SELECT email FROM users WHERE name = (:name)", name: "bob")

# Prepare a statement for querying
{:ok, qstmt} = Turso.conn_prepare(conn, "SELECT id, name FROM users", false)
{:ok, rows} = Turso.stmt_query(qstmt, [])
# rows = [[1, "alice"], [2, "bob"]]

As you can see, the Turxo v0.1.0 release is at a very early state with only the raw Rust bindings and lacking in docs. I decided to release it nonetheless to make it available to the public for feedback. Here are the immediate features I have on the Roadmap (PRs welcome!):

Transactions
DBConnection integration
Pragmas

Particularly, I would appreciate any help in overhauling my test suite to something more robust and comprehensive than the handwritten example-like test I have now.

I also plan to write Ecto and Ash adapters in separate repositories.

Let me know any feedback you may have.

7 comments

#library #databases #sql #ecto_sql #ash-sqlite #turso #turxo

9 458 7

2026-07-27 20:52:55 UTC

Most Liked

glauber

Hello! This is really good. I am the creator of Turso

Any reason why you wouldn’t submit this to the Turso tree? We’ve been keeping the bindings in tree, and that helps a lot with regression tests, making sure features are added to new drivers, etc.

Post #1

Benjamin-Philip

Hi Glauber, welcome to Elixirforum!

When I started the project, I didn’t think about it too deeply. Culturally in the Erlang/Elixir ecosystem, we tend to keep bindings/implementations within the Elixir community. In the case of databases, almost none of the database drivers (see the Ecto project) have been upstreamed. There’s a similar pattern with message queue adapters (see the Broadway project), gRPC, Protobuf and even generally in smaller libraries. I’m not sure why this is the accepted practice, but my decision to build outside of the Turso tree is very much just me following established norms. Though, recently I have been trying to change this with my work upstreaming the Erlang implementation of Apache Arrow to the ASF.

However, I’m happy to upstream this to Turso if you’re interested. I think that first party status is generally better for the quality and health of the project.

My original motivations for writing this library do partially clash with upstreaming though. As a young student, I approached this as a learning exercise, not because I needed to use Turso, whilst still addressing a genuine gap in the community. The learning was partially technical, but my primary motivation was to learn what was involved in being a maintainer. Things like:

Release processes
Handling issues and PRs
Maintaining code quality in contributions
Growing a userbase as well as contributors

My thought was building something production-grade myself would expose me to these responsibilities. My worry with upstreaming is that I would learn less about maintenance since most of the load would be handled by the Turso team.

That said, I still think upstreaming is what’s best for the library. Maybe if we can come to some understanding over the level of oversight I would have if I were to upstream, perhaps we can work something out.

You’ve clearly not looked at the code. I personally don’t consider it release worthy as-is, and I am quite disgusted with myself over the lack of documentation. It was only after my dad convinced me that a release was more meaningful and useful than a lone git repo, that I released a v0.1.0.

Post #2

dimitarvp

I am super close to officially releasing and announcing Xqlite — Xqlite v0.10.0 and now I wonder whether we should join forces and have one adapter that can “quack” multiple breeds of SQLite3. Had my eye on Turso for a long time and almost lost hope they’ll come through. Thanks for the confirmation, @glauber!

Post #4