Tarantool Community Edition

How Tarantool works

Tarantool keeps all the data in random-access memory (RAM). Solutions of this class are fast, but they often lack data persistence. Tarantool helps overcome these problems. Try Tarantool to see how fast, flexible, and scalable it is.


When to use in-memory?

In-memory solutions are very fast because they work in RAM. This helps you avoid overhead associated with caching and uploading. Plus, the memory-resident approach reduces TCO—the database utilizes the processor more efficiently, so you need fewer servers. There are four main cases where an in-memory database is a good fit for application development:

OLTP with the highest possible throughput for large numbers of simple requests

Speeding up a slow application or a database by using a caching proxy

The existing message brokers can’t keep up with the workload

You need predictable response time from the system

Why use Tarantool?

Combined DBMS and application server

Using the Lua programming language, you can add any data processing logic directly to the database. The code and the database share a single address space, so your applications don't use the network. In this way, you avoid latency in operation processing. Besides Lua runtime, Tarantool also provides the LuaJIT compiler, which generates optimized code for hot paths in your application.

Two storage engines: in-memory and disk

By default, Tarantool uses memtx, the in-memory storage engine. If the amount of data exceeds the RAM capacity, it's recommended to move rarely accessed historical data to the disk storage engine, vinyl. This approach helps optimize resources: instead of linking an in-memory database to a traditional one, you only use Tarantool.

Secondary indexes

You can create indexes for any data in Tarantool. Searching indexed fields is faster and more predictable. If you need to select similar data based on several criteria, you can create multiple indexes for a single table. Tarantool supports both regular and JSON indexes.

Hybrid data storage model

Tarantool lets you choose a data storage model. When the names and number of fields are unknown, it's best to use the JSON format or tuples. Otherwise, tables are the best option. You can specify a format that records data types in columns—for your entire table or only for a part of it. A table with a specified data format can be accessed using SQL queries.

Try Tarantool now or request a demonstration from our product experts

Guaranteed data persistence in Tarantool

Working in RAM doesn't mean that you risk losing all your data. Tarantool has embedded mechanisms that ensure data safety.

Write-ahead logging

Both in-memory and disk storage engines use write-ahead logging. The transaction result returns only after it's been saved to disk. Even an unexpected server restart wouldn’t cause data loss.

Synchronous replication

When a disk or a server fails, replication helps prevent data loss. In Tarantool, the replication lag is typically 100–200 microseconds, which is equal to network latency and virtually reduces the probability of data loss to zero. You can configure synchronous replication only for critical data in specific tables for a full guarantee of persistence.

Tarantool is ACID compliant

ACID stands for atomicity, consistency, isolation, and durability. In-memory databases often sacrifice durability. This is related to the very principle of RAM storage, which carries the risk of losing some information in case of failure or restart. To minimize this risk, Tarantool uses the following:

Write-ahead logs

Data state snapshots

Synchronous writes to several replicas

Download Tarantool and check its speed and reliability


a consultation

a demo

Thank you for your request

Tarantool experts will contact you shortly