Tarantool: an in-memory database and Lua application server in one process

What Tarantool solves, and for whom

The README describes Tarantool as "an in-memory computing platform consisting of a database and an application server." That single sentence is the whole pitch. Instead of running a database in one process and your application logic in another, you store tuples in RAM and execute Lua functions in the same process that owns the data. The network hop between application and storage disappears.

The intended audience is stated plainly: Tarantool is "ideal for data-enriched components of scalable Web architecture: queue servers, caches, stateful Web applications." Those three examples share a shape. They are read-heavy, they hold working state rather than archives, and they benefit from logic running close to the data. A queue server needs to pop, retry and expire items without a round trip per operation. A cache needs sub-millisecond lookups. A stateful web application needs to mutate session or game state atomically.

It is a poor fit for analytical workloads, for data sets that cannot fit in memory, and for teams that want a database they can operate without writing any application code inside it. The project ships SQL, but the primary interface is Lua plus the MessagePack-based client-server protocol, and that shapes everything about how you use it.

Two engines, two very different storage stories

The database half offers two engines, and the choice between them is the most consequential decision a new user makes. The first is "100% in-memory with complete WAL-based persistence." Every tuple lives in RAM; durability comes from a write-ahead log on disk. Restart replays the log. Memory is the hard ceiling on data size, and the log is the hard requirement for not losing writes.

The second engine is "an own implementation of LSM-tree, to use with large data sets." This one trades the pure in-memory model for on-disk storage with a log-structured merge structure. It exists precisely because the first engine cannot hold everything.

Both engines sit under the same index types: HASH, TREE, RTREE and BITSET, plus document-oriented JSON path indexes. That index set is broader than what most key-value stores expose. RTREE gives you spatial indexing; BITSET gives you set-membership queries; JSON path indexes let you index into document fields without a separate document database.

On replication, the README lists three distinct modes: asynchronous master-master, synchronous quorum-based, and RAFT-based automatic leader election for a single-leader configuration. Those are not interchangeable. Master-master accepts writes on any node and resolves conflicts after the fact; quorum-based synchronous replication refuses a write until enough replicas acknowledge it; RAFT picks one leader and routes writes through it. Picking the wrong one for your consistency requirements is a design error you will discover in production.

Installing Tarantool and writing your first stored function

The README does not walk through installation itself. It points to the download page for binary packages per OS and for Docker, and to a separate document for building from source. So the concrete paths below are the ones the repository layout supports, not a tutorial the README contains.

The documented path for most users is a binary package from the download page. On Debian and Ubuntu systems the repository ships a debian/ directory, and the project publishes rpm/ and apk/ packaging trees as well, which indicates native packages for those families rather than a single universal installer.

For a container-based trial, the repository carries a docker/ directory, and the download page is where the README sends readers for the Docker route. The README itself does not print a docker run command, so take the image name and tag from the download page rather than from the front page of the repository.

Once you have a shell, Tarantool starts as a Lua REPL. You create a space (the equivalent of a table), define a primary index, and insert tuples. The README gives no code sample, so what follows is the standard shape of the API rather than a quoted example: a space is created with box.schema.space.create, an index with space:create_index, and rows are written with space:insert and read with space:select. Because the database is described as "a C extension of the application server," all of this runs through the same Lua process that would host your application logic.

For a longer-lived setup you write that logic into a Lua file and start Tarantool with it, so the schema and the stored functions load together at boot. The README does not document a rollback procedure for schema changes, and it does not document an upgrade path between the 2.11 and 3.x release lines.

Where Tarantool is the wrong tool

The in-memory engine has an obvious failure mode: when the data set exceeds available RAM, it stops being viable. The README offers the LSM-tree engine as the answer for large data sets, but that is a different engine with different performance characteristics, not a transparent overflow. You are choosing a storage design, not flipping a flag when you run out of memory.

Durability is the second constraint. The in-memory engine is described as having "complete WAL-based persistence," which means every committed write goes through the write-ahead log. If the disk backing that log cannot keep up with your write rate, or fills up, the persistence guarantee is what breaks first. The README does not discuss WAL sizing, rotation or what happens on disk exhaustion.

The third limitation is the interface. The database is a C extension of the application server and "can be turned off," which tells you the project's centre of gravity is the combined platform, not a standalone database you point an ORM at. If your team wants to write application code in a general-purpose language and treat storage as a black box, Tarantool asks you to accept Lua in the critical path. That is a real organisational cost, and the README does not pretend otherwise.

Finally, the README does not document rollback, upgrade compatibility between release lines, or operational runbooks. Those gaps matter more than the feature list when you are the one on call.

How it differs from Redis and from PostgreSQL

The comparison people search for most is Tarantool against Redis, and the architectural difference is worth stating precisely. Redis is a data-structure server: you get strings, lists, hashes, sets and streams, plus a scripting facility. Tarantool is a database with typed spaces, named secondary indexes across four index types, JSON path indexes, and ANSI SQL including views, joins, referential and check constraints. It also gives you a Lua application server in the same process, with a tracing JIT compiler based on LuaJIT 2.1 and cooperative multitasking with non-blocking IO. In Redis, the scripting layer is a way to extend a cache. In Tarantool, the application server is half the product.

Against PostgreSQL the split is the other way. PostgreSQL is a general-purpose disk-based relational database with decades of operational tooling. Tarantool's default engine is memory-resident, and its persistence model is a WAL rather than a buffer pool over heap files. If your data comfortably exceeds RAM and your queries are ad-hoc and analytical, PostgreSQL is the correct default and Tarantool is not.

The honest framing: Tarantool competes with Redis on latency and with PostgreSQL on data modelling, and it wins only when you actually use the application server. If you deploy it purely as a key-value store, you are paying the operational cost of a database platform for the benefit of a cache.

Licence, maintenance and what an upgrade actually costs

Tarantool is distributed under BSD 2-Clause terms, per the README. That is a permissive licence, which generally means you can embed it in commercial products without a copyleft obligation on your own code. The repository's licence field is reported as NOASSERTION by the hosting platform, so if licence terms are load-bearing for your legal review, read the LICENSE file in the repository root rather than trusting the metadata. Nothing here is legal advice.

The repository is not archived, and the last push was on 2026-09-23. The release cadence is visible in the recent tags: 2.11.10 on 2026-09-22, 3.8.1 on 2026-09-04, and 3.8.0 on 2026-07-10. Two lines are being maintained in parallel, a 2.11 series and a 3.x series. That parallel maintenance is the upgrade cost. The README does not document a migration path between them, so the work of moving from 2.11 to 3.x is something you will have to reconstruct from the changelogs/ directory and the release notes, not from the front page.

Operationally, budget for the WAL. It is the component that turns an in-memory store into a durable one, and the README does not describe its sizing or failure behaviour.

Editorial conclusion

Adopt Tarantool when your workload is read-heavy state that fits in RAM and you want the business logic to run next to the data instead of in a separate service. Skip it if your data set outgrows memory and you expect the LSM-tree engine to behave like a general-purpose disk database, or if your team has no Lua experience and no appetite to gain it. Before committing, verify two things against your own workload: how the memtx engine behaves when the WAL disk fills up under your write rate, and whether the 2.11 or 3.x release line is the one your connectors and modules actually support.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. tarantool/tarantool on GitHub