Skytable: a Rust NoSQL database with BlueQL and a column-oriented model

What Skytable replaces, and for whom

Skytable is a NoSQL database server implemented in Rust. The README describes it as primarily in-memory, using multithreaded asynchronous I/O and a custom AOF-based storage engine with delayed durability transactions. That combination is the pitch: fast reads and writes from memory, with disk writes batched rather than forced on every operation.

The target reader is an application developer who has outgrown a plain key-value store but does not want a relational schema. Skytable's answer is a column-oriented data model with spaces instead of databases. The README explains the naming directly: spaces store a lot more than tabular data, which is why the project did not call them databases.

It is not a drop-in Redis replacement. Redis hands you strings, hashes, lists and sets through commands; Skytable hands you models with declared field types and a query language. The README's own example defines a model with a username, a password and a list of strings, and shows the equivalent Rust struct. If your workload is mostly GET and SET, that type layer is overhead you are paying for and not using.

Spaces, models and how BlueQL parameterises queries

The data model has two levels. A space is the top-level container, and a model is a typed record definition inside it. The README's example creates a space, switches to it, then creates a model whose fields include a list of strings. Collections are part of the type system, not an afterthought bolted onto string values.

Querying happens through BlueQL, which the README describes as a SQL-based query language written specifically for Skytable and hardened against injection attacks. The mechanism behind that claim is mandatory parameterisation. The README states this explicitly and notes that the REPL hides it: when you type literal values into skysh, the client parameterises the query behind the scenes. In the Rust driver you pass placeholders and bind values separately, as the README's example does with a question mark in the WHERE clause.

That is a real design decision with visible consequences. You cannot build a query by concatenating user input into a string and expect it to work the way it does in a database that accepts raw literals over the wire. The wire protocol wants parameters. For application code that is fine, and arguably better. For ad hoc scripting through a raw socket, it means you either use the official client or implement the parameterisation yourself.

The README also states that the column-oriented structure supports additional data models as work in progress, and points to docs.skytable.io/architecture for clustering, high availability and the current limitation list. Treat that page as required reading, because the README does not reproduce the limitations itself.

Installing Skytable from the release bundle and running a first query

The README gives a four-step path. You download a bundled release file from the GitHub releases page and unzip it. There is no package manager step in the README, so on a fresh machine you are working from the archive rather than from a distro repository. The repository does contain a Dockerfile and a Makefile with bundle, deb and audit targets, which tells you how the maintainers produce those artefacts, but the README's instructions for users start at the releases page.

Once unzipped, start the server with a root password of your choosing. The root account is described in the README as equivalent to a Unix root account with control over everything.

./skyd --auth-root-password <password>

Then start the interactive client and enter that password when prompted.

./skysh

Inside the REPL, create a space and switch into it. The README notes that the REPL parameterises values for you, so literals typed here are safe to write directly.

CREATE SPACE myspace
USE myspace

Next define a model. Field types are declared inline, and list types carry their own element type.

CREATE MODEL myspace.mymodel(username: string, password: string, notes: list { type: string })

Insert, update and read a record. The update uses the += operator to append to the list field, which is where the typed model starts to pay off compared with storing an opaque blob.

INSERT INTO mymodel('sayan', 'pass123', [])
UPDATE mymodel SET notes += "my first note" WHERE username = 'sayan'
SELECT * FROM mymodel WHERE username = 'sayan'

If the SELECT returns the row you inserted with the note appended, the server, the space and the model are all working. From there, application code needs a client driver rather than the REPL.

Using Skytable from Rust, and the driver situation elsewhere

The README states that you need a client driver to use Skytable in your programs, and that the officially maintained one is the Rust client driver, licensed under Apache-2.0 so it can be used anywhere. That licence split matters: the server is AGPL-3.0 while the Rust driver is Apache-2.0, so linking the driver into a proprietary application is a different question from modifying and redistributing the server. The README does not spell out the boundary, and this is not legal advice, but the two licences are not the same and the difference is worth checking with whoever handles licensing on your side.

The README's Rust example is short. You build a Config with credentials, connect, construct a query with the query! macro and a bound parameter, then parse the result into a tuple.

use skytable::{Config, query};

fn main() {
    let mut db = Config::new_default("username", "password").connect().unwrap();
    let query = query!("select username, password from myspace.mymodel where username = ?", "sayan");
    let (username, password): (String, Vec<u8>) = db.query_parse(&query).unwrap();
    // do something with it
}

The macro and the tuple destructuring are the interesting part. The type system carries the result shape, so a schema change that alters column order shows up as a compile error or a parse failure rather than a silent misread. The README points to docs.skytable.io/libraries for the full driver list and invites contributions for other languages, which is a fair signal that non-Rust drivers are community work rather than first-party guarantees. If your stack is not Rust, verify the driver you intend to use before designing around Skytable.

Where Skytable is the wrong choice right now

The clearest limitation is stated by the project itself. A new version, Skytable 0.9, has been in development for a while and is nearing completion. It adds clustering, new data types and advanced querying features. The README says the code is currently on a private repository and will be available on the crv1 branch, and that the branch you are reading contains the source for Skytable 0.8.

So clustering is not in the version you can download today. If your requirement is a multi-node deployment with automatic failover, Skytable 0.8 does not offer it, and the README's architecture page is where the project documents the clustering and HA work in progress. The latest release listed for the repository is v0.8.4 from 2024-08-07. The repository's last push was on 2026-04-23, so work is happening, but the released artefacts lag behind the branch.

A second constraint is the in-memory design. The README describes Skytable as primarily in-memory with delayed durability. Delayed durability is a trade-off: it is efficient for disk I/O, and it means a crash can lose the most recent writes that had not yet been flushed. The README does not document the exact durability window, and it does not document rollback behaviour. If your workload cannot tolerate any acknowledged-write loss, that gap in the documentation is itself a reason to test carefully before trusting it.

Third, the additional data models beyond the column-oriented structure are marked WIP in the README. Do not plan around them.

Skytable compared with Redis and with a relational database

The comparison people search for is Skytable versus Redis, and the difference is in the data model rather than the storage medium, since both keep data in memory. Redis gives you a fixed set of data structures and a command per operation; there is no schema and no query language. Skytable gives you declared models with typed fields and collections, and BlueQL with mandatory parameterisation. If you want to evolve a record shape and have the client catch mismatches, Skytable's model layer does work Redis pushes into your application code. If you want a cache with a TTL and nothing else, Redis is simpler and has a much larger driver ecosystem, which the README implicitly acknowledges by asking for help writing drivers for other languages.

Against a relational database the split is different again. Skytable is not trying to be one. Spaces are not databases in the relational sense, and the README is explicit that spaces hold more than tabular data. What you give up is the relational machinery: joins, constraints and the decades of tooling around SQL. What you get is a column-oriented store with collections in the type system and a query path designed around bound parameters. If your access pattern is record lookup and field update by key, that is the shape Skytable is built for. If you need to join three tables and aggregate, look elsewhere.

Maintenance, releases and what the licence means in practice

The repository is not archived. Its last push was on 2026-04-23. The most recent tagged release is v0.8.4 from 2024-08-07, preceded by v0.8.3 and v0.8.2 in 2024. That gap between the last release and the last push is the thing to weigh: the branch is moving, but the downloadable bundles are older than the branch. If you build from source you are on the branch; if you use the release bundle you are on 0.8.4.

Upgrade cost is dominated by the pending 0.9 work. The README says 0.9 adds clustering, new data types and advanced querying features, and that the code will appear on the crv1 branch. New data types and query features are the kind of change that can alter how existing models and queries behave, so plan for a migration rather than an in-place binary swap. The README does not document a migration path from 0.8 to 0.9, and it does not document rollback.

The server is AGPL-3.0. If you run a modified Skytable as a network service, the AGPL's network clause is the part your legal reviewers will want to look at, because it reaches users interacting with the software over a network. Running the unmodified server as a backend for your own application is a different situation from shipping a modified fork. The Rust client driver is Apache-2.0, which the README describes as deliberately liberal so you can use it anywhere. The repository also contains a SECURITY.md and a CODE_OF_CONDUCT.md, and contributing is routed through CONTRIBUTING.md.

Editorial conclusion

Adopt Skytable if you want a Rust-first, in-memory store with a typed data model and you can live inside the 0.8 feature set. Do not adopt it if you need clustering today: the README states that Skytable 0.9, which adds clustering, is in development on a private repository and will land on the crv1 branch. Before committing, check the release bundle for your platform, confirm the server starts with ./skyd --auth-root-password, and read the architecture page at docs.skytable.io for the limitation list the README points to.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. skytable/skytable on GitHub