GlueSQL: an embeddable SQL engine that queries the storage you already have

The problem GlueSQL solves: SQL without moving your data

Most SQL databases assume you will bring your data to them. GlueSQL inverts that. The README describes it as an embeddable, multi-model SQL database engine written in Rust that "brings SQL to your application's storage." The engine handles parsing, planning and execution; a storage adapter handles reads and writes. If your records already sit in a Redis instance, a MongoDB collection, a Parquet file or a Git repository, you can query them in place instead of exporting them into a separate database first.

The second problem is shape. Traditional SQL demands a schema before the first insert. GlueSQL does not require every table to have one. A schemaless table can hold rows with different fields, and MAP and LIST values cover semi-structured data. The README's own example creates a schema-defined Names table and a schemaless Logs table, then joins them on id in a single statement, with missing fields coming back as blanks.

Who this is for: Rust and JavaScript developers building tools, notebooks, local analytics or browser applications where a database server is either impossible or disproportionate. It is also for teams whose data lives in an existing store and who want SQL as a query layer rather than a migration target.

How the engine and its storage adapters fit together

The workspace layout makes the split explicit. Cargo.toml lists a core crate alongside a storages directory whose members are separate crates: gluesql_memory_storage, gluesql-shared-memory-storage, gluesql_sled_storage, gluesql-redb-storage, gluesql-json-storage, gluesql-csv-storage, gluesql-composite-storage, gluesql-redis-storage, gluesql-mongo-storage, gluesql-parquet-storage, gluesql-file-storage and gluesql-git-storage. Each is versioned with the workspace at 0.20.0. You depend on the core engine plus the one or two storage crates you actually need.

Custom backends are the intended extension point. The README states that creating a custom storage requires implementing the Store and StoreMut traits. That is a narrow surface compared with writing a full database, and it means the engine's SQL surface stays constant while the persistence layer changes underneath.

The composite storage is the interesting case: the README lists it for "queries across multiple storage backends." That is where GlueSQL stops looking like an embedded library and starts looking like a federation layer. Whether cross-backend joins push work down efficiently is not something the README addresses, and the storage documentation points to per-storage limitations rather than a single performance page.

There are two query interfaces over the same engine. You can write SQL, or you can compose statements with the Rust Query Builder. The README is explicit that the builder produces executable statement plans directly rather than generating SQL for another engine, which is why it can accept SQL fragments and builder methods in the same chain.

Installing GlueSQL and running a first join

The Rust path is a single command. The README gives cargo add gluesql, which pulls the engine crate into your project. For JavaScript the equivalent is npm install gluesql, and the browser build is importable directly from a CDN URL.

cargo add gluesql

After that you add the storage crate for your target. The README's table recommends Redb for a persistent embedded database, Memory or Shared Memory for temporary data, tests and prototypes, and CSV, JSON or Parquet when you are querying files.

With the engine in place, the README's schemaless example is the shortest path to seeing what makes GlueSQL different. It creates one ordinary table and one table with no column list at all, inserts JSON string literals into the second, and joins them.

CREATE TABLE Names (id INTEGER, name TEXT);
INSERT INTO Names VALUES (1, 'glue'), (2, 'sql');

CREATE TABLE Logs;
INSERT INTO Logs VALUES
    ('{ "id": 1, "value": 30 }'),
    ('{ "id": 2, "rate": 3.0, "list": [1, 2, 3] }'),
    ('{ "id": 3, "rate": 5.0, "value": 100 }');

SELECT * FROM Names JOIN Logs ON Names.id = Logs.id;

The output the README shows has five columns: id, list, name, rate and value. Row 1 has a name and a value but no list or rate; row 2 has a list and a rate but no value. Columns appear because some row somewhere defined them, and absent fields are blank rather than an error. That is the behaviour to internalise before designing a schema around it.

The Query Builder reaches the same engine from Rust, mixing a SQL filter string with a typed column comparison.

table("Foo")
    .select()
    .filter("name = 'Lemon'")
    .filter(col("price").gt(100))
    .project("id, name")
    .execute(&mut glue);

Where GlueSQL is the wrong tool

Schemaless tables are the feature most likely to be misread. Columns in a result set are inferred from the rows present, so a query that works against today's data can return a different shape tomorrow when a new field shows up or an old one disappears. There is no declared contract to validate against. If your application code destructures a result by position, schemaless tables will eventually break it.

The storage model is the second constraint. Every backend is a separate crate at the same version as the workspace, so a storage crate that lags or is not in the members list is not something you can depend on at that version. The README's truncation aside, the listed members are the ones the workspace builds. Anything outside that list is community territory.

Third, GlueSQL is a library, not a service. The README describes an engine and a set of adapters. There is no mention of a network protocol, replication, failover, connection pooling or backup tooling. If you need multiple processes writing concurrently to one store, or a client library in a language other than Rust and JavaScript, this is the wrong layer. The README's supported language surface is Rust and JavaScript; the topics list mentions WebAssembly and WebSQL, which points at browser use rather than server deployment.

Finally, the Query Builder's design is a deliberate trade-off. Because it builds statement plans instead of generating portable SQL, the queries you write are GlueSQL queries. Moving that code to another engine means rewriting it, not swapping a connection string.

How GlueSQL differs from DuckDB and from a query engine like DataFusion

The nearest comparison in spirit is DuckDB, which also embeds in-process and also reads files directly. The difference is in what the engine is allowed to sit on. DuckDB owns its execution and storage format; GlueSQL delegates storage to adapters and expects you to supply one, whether that is Redb, Redis, Mongo, a Git repository or a trait implementation of your own. If your data is already in Redis, GlueSQL's Redis storage is a query layer over it, while DuckDB would want the data in its own format first.

Against a Rust query engine such as DataFusion, the split is similar but the emphasis differs. GlueSQL's README foregrounds schemaless tables, MAP and LIST values, and the two-interface design of SQL plus Query Builder. It also ships a CLI crate in the workspace, which the README does not document in detail. The practical distinction for a reader is scope: GlueSQL positions itself as a database engine with pluggable persistence, not as a query planner you wire into a larger system.

The composite storage is what neither comparison covers cleanly. Querying across multiple backends in one statement is a federation problem, and the README lists the capability without describing the execution strategy. Treat that entry as a pointer to the storage documentation rather than a guarantee about how joins across adapters perform.

Maintenance, versions and the Apache-2.0 licence

The last push to the repository was on 2026-09-23, and the most recent release is v0.20.0 from 2026-08-30. The release cadence visible in the repository is roughly one minor version per several months: v0.18.0 in June 2025, v0.19.0 in January 2026, v0.20.0 in August 2026. That is a slow, deliberate cadence, and it means an upgrade is an event rather than a background task.

Upgrade cost is shaped by the workspace versioning. The engine and every storage crate share the workspace version, currently 0.20.0, and the README's storage links are versioned into the documentation path, for example /docs/0.20.0/storages/. Pinning the engine without pinning the matching storage crate at the same version is the obvious way to get a mismatch. Before upgrading, check that each storage crate you depend on carries the new workspace version.

The project is licensed under the Apache License, Version 2.0, stated in the README and in the workspace package metadata. Apache-2.0 is permissive and includes an express patent grant. That is not legal advice: if you redistribute GlueSQL inside a product, read the LICENSE file in the repository and confirm the notice and attribution requirements against your own distribution model.

One maintenance signal worth noting: the README points contributors at the test suite and the SQL fixtures under test-suite/fixtures as a starting point, and describes the suite and CI as guardrails that catch regressions before merge. That is a claim about process, not a measurement.

Editorial conclusion

Adopt GlueSQL when the data already lives somewhere you control and you want SQL over it without a server: CSV, JSON, Parquet, Redis, Mongo, or a custom Store implementation. Do not adopt it expecting an operational database with a wire protocol, replication or a backup story; the README and the storage table describe adapters, not deployment. Before committing, verify that your chosen storage crate appears in the workspace members list at the version you pin, and that the operations you need are covered by the storage documentation's limitations page. The project is licensed Apache-2.0, so check that the terms suit your distribution model before shipping.

Frequently asked questions

Official sources

1. gluesql/gluesql on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases