Turxo - bindings to the Turso database

Benjamin-Philip

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 772 7

2026-07-27 20:52:55 UTC

Showing Posts 1 to 7

Show Best Posts
Show All (oldest first)
Show All (newest first)

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

taro

Lovely name. Thank you for the initiative. I’m sitting on libSQL until something matures for Turso; can’t wait for v1.0. It’s worth mentioning ex_turso and turso_ex here since it seems they are not posted in this forum.

Post #3

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

glauber

@Benjamin-Philip your father is right! ship early, ship, ship, ship! Tell the man I sent my regards, and wild to see you already doing this at high school age. My oldest is 7 and I wish he follows your path.

You are right that I didn’t look at the code. When I said it is very good, I was referring to the fact it exists.

To both you and @dimitarvp : First, thanks for the warm welcome in this community! We at Turso want to make sure Turso integrates well with as many ecosystems as possible. In no way you are required to send the code back to Turso, but we do want to make it clear that if you want to, the door is open. We have found a lot of success with drivers in tree, because we can then integrate with our CI and make sure new released don’t break it. But that’s not always possible. For go for instance, it’s a bit weird because Go uses git trees as import paths, and putting everything in the same tree causes friction.

One model that I think works well is if you bring the core driver into Turso, but for higher level adapters like native ORMs you keep it outside.

It truly is whatever works best for you and your community! We’re here to help.

Post #5

Benjamin-Philip

This sounds like the way to go. Maintaining the ORM adapter out of tree addresses my learning goals. Since I started the project out of tree, I’ll smoothen the rough edges over a couple of releases myself, and later submit a more complete version to the tree.

Post #6