Features include fully ACID transactions with rollbacks, complex queries, and sophisticated stored procedures. Tarantool can read SQL statements that conform to the newest SQL standard, SQL:2016, and it can also be extensively scripted with LuaJIT.

DBAs generally consider adding Tarantool to a SQL Server stack after they have expensively replicated and sharded the stack but find that they are still frustrated by its performance — or at least the costs they are incurring with added performance. Often, a DBA will first try to fix performance issues with a traditional in-memory cache like Memcached or Redis. This will help in some ways but also will cause the loss of relational properties such as reliable transactions and data issues from cache invalidation.

Adding Tarantool to a SQL Server stack maintains those relational properties — including ACID transactions, complex queries, and secondary indexes — while simultaneously yielding substantial savings, both in terms of raw hardware as well as licensing costs. Also, it adds a full application server into the mix.

SQL Server community often gradually struggles to restructure for a microservices architecture. This approach makes it simpler and easier.

Tarantool’s engineering is a natural fit for microservices because it can be run in multiple independent instances, each with full network I/O, and each potentially having its own data store. These instances can make HTTP calls, for example, and can also serve data themselves (the largest known number of instances in a Tarantool installation is around 500). An example use case of Tarantool in a microservices architecture is an authentication service for logging users into a web application. Because Tarantool features a full DBMS, the entire service could begin and end with a small Tarantool instance — without being attached to a larger relational DBMS at all.

On Windows-based machines, Tarantool can be run with Docker, or it can be run in the Tarantool app on Azure. SQL Server data is replicated into Tarantool through log reading, and this replication is enabled by Tarantool’s enterprise partners like Continuent and Informatica. Additionally, the open-source community has built a .NET connector, ProGaudi, which enables the calling of Tarantool’s API from C#. ProGaudi has been engineered to work with Tarantool’s protocol, IProto, as well as MessagePack, its serialization format. Technically speaking, MessagePack is actually more efficient than JSON, which it accomplishes by being less human-readable, but easier for machines to parse.

Tarantool can replicate more than just SQL Server data: PostgreSQL, MySQL, DB2, and Oracle can all be replicated, as well — simultaneously or singly. After data is federated in Tarantool, it can be pulled, for example, into front-end business intelligence tools like QlikView, Cognos or Tableau. It is faster and cleaner to federate data in Tarantool and then present it to BI solutions than it is to try and pull the different data streams directly into those solutions.

Tarantool can dramatically downsize and accelerate an existing SQL Server stack by taking over work from expensive servers. It can also allow the refactoring of a stack by adopting some of the stack’s individual functions as microservices. And Tarantool was born for heavy workloads: it is used in half of the applications of one of the world’s largest Internet companies, specifically in its email, cloud, social media and messaging properties. This company, Tarantool’s parent, stores the user profiles of its 100 million active accounts on a grand total of eight servers that run Tarantool, a feat that would require hundreds of servers in an RDMS setup.