Install

TessariDB is one binary. There is no server package to install beside a client package, no JVM, no separate agent, and no configuration file that has to exist before the process will start.

If you only want a node running, you do not need this page. The published image needs no repository access and no toolchain: docker run -p 9080:9080 -p 8000:8000 tessaridb/tessaridb — see In a container, which also lists every variable it reads and the one that decides whether your store is open to the network. This page is the build from source.

Where the source is

The engine's repository is private while this is a pre-release, so the build below does not begin with a public clone. Access is given on request: write to hello@tessaridb.com and say what you intend to build.

Access and licence are separate questions, and only the first one is gated. The licence is BUSL-1.1, and under its Additional Use Grant TessariDB is free — no agreement, no charge — for any use, including production, including inside a commercial organisation, and including inside a product you sell. The one restriction is that you may not provide TessariDB to third parties as a database service: an offering in which TessariDB gives database functionality to people outside your own staff and contractors, where those people can create or control namespaces, databases, tables or schemas. That needs a commercial licence — licensing@tessaridb.com, or tessaridb.com/licensing.

Each version becomes Apache-2.0 on 2030-08-24, or four years after it is first published, whichever comes first.

Two parts of the project are public now and need no permission:

This site is worth reading before you have a build. It describes the engine as it behaves today rather than as it is planned to behave, and the examples are run against the engine before a page ships — see The examples are executed.

What you need

Nothing else. No system libraries are dynamically loaded at run time, which is why the release binary can be copied to a machine that has none of the above.

Building it

cargo build --release

The result is target/release/tessaridb. The release profile is deliberate about a few things:

The first build takes a while and most of that is the storage engine's native sources compiling with no output at all. A silent build log here is the normal state and not a hung process.

Then ask the binary what it is, which needs no store and is therefore the one question it can always answer:

$ tessaridb --version
tessaridb 0.34.2-beta

What you get

One command with three shapes, and which one you get is decided by an argument rather than by a different program:

The same binary is the client, the server and the shell. There is no second executable to keep at the same version as the first — a class of problem that only exists once you have two.

Versions

This is 0.34.2-beta — what tessaridb --version answers. The number is not modesty: the language and the wire format are still moving.

The on-disk format is held from 0.27.0-beta. A store written by 0.22.0-beta or any release since opens under a newer build and reads back what the build that wrote it answered — the engine's own tests open a store each of those releases wrote, and each later release adds its own — with an older layout rewritten at open where it has to be. A store written in a newer format is refused rather than opened, and so is a directory holding data with no format stamp; either is left untouched. Going back to an older build is not promised, so take a backup before an upgrade and keep one you have restored (Backup and restore).

The protocol is versioned separately and independently, because a client and a node are upgraded at different times by different people. See The protocol.

Next

• In a container — the published image, when you would rather not build at all.
• Your first store — a table, a record, and a read, from the prompt the binary just gave you.
• The prompt — what the shell does with a script, and what it does between statements.
• Connecting — when the store should outlive the prompt.