1. Introduction

1.1 What is MIRAJ#

MIRAJ is a columnar, in-memory, durable relational SQL database engine, developed by CIRTASOFT (https://mirajdb.com). It stores the data of each table column by column, keeps those columns in memory for query execution, and guarantees write durability through a write-ahead log that is replayed at restart.

MIRAJ is intended for:

developers who want to embed a fast SQL engine in an application (desktop, service, data-processing tool) without depending on an external server;
developers building classic client/server applications who want a SQL server reachable over the network and compatible with existing tools and connectors;
database administrators (DBAs) who operate one or more MIRAJ servers: account creation, privilege management, monitoring, backups, replication.

Typical use cases: business applications with an embedded local database, a data server for a client/server or web application, analytical computations on data volumes that fit in memory, consolidation of several databases behind a single server, and cluster deployment for read availability.

This manual is intended for MIRAJ end users (developers and DBAs): it describes the SQL language, the bundled tools (miraj-cli, miraj-server) and their administration. It does not describe the internal implementation of the engine.

1.2 The three ways to use MIRAJ#

Mode	Description	Intended for
Embedded	The engine runs inside the application's process, through the native Rust API or through the dynamic library `miraj.dll` (C API) and its Delphi unit `Miraj.pas`. No separate process, no network connection.	Applications that embed their own data, with no server to deploy.
Command line	The interactive SQL console `miraj-cli` opens a data folder and executes SQL statements, either interactively (REPL) or by running a `.sql` file.	Administration, scripts, ad hoc data exploration.
Network server	`miraj-server` listens on a TCP port (7007 by default) and serves SQL sessions to remote clients, using the standard market SQL client/server protocol: existing connectors, administration tools and clients connect to it without adaptation.	Client/server applications, web applications, concurrent access by several applications to the same database.

These three modes share the same engine and the same data file format: a database opened in embedded mode can later be served by miraj-server, and vice versa.

1.3 Product editions#

MIRAJ is distributed in three editions, built from the same code:

Edition	Parallelism	Price	Use case
Standard	Large queries (filters, projections, aggregation, sorting, `DISTINCT`, some joins, reading for bulk writes) are spread across several cores.	Paid	Workloads where execution speed of large queries matters.
Express	Each query runs on a single thread, with no intra-query parallelism.	Free	Lightweight applications, development, testing, small workloads.
Cluster	Standard, plus multi-node replication: a primary node accepts writes, secondary nodes receive its log and replay it continuously, read-only.	Paid	Read availability, read load balancing, preparation for a distributed deployment.

The three editions speak the same SQL and read the same data files; only the distribution of work across cores and replication differ.

Finding out which edition you are using#

SELECT @@miraj_edition;
-- 'Standard', 'Express' or 'Cluster'

SELECT @@version_comment;

SHOW ENGINES;

VERSION() returns the same version number regardless of the edition; it is @@miraj_edition, @@version_comment and SHOW ENGINES that distinguish Standard, Express and Cluster.

1.4 Architecture overview#

Seen from the outside, a MIRAJ engine rests on four principles:

Columnar, in-memory storage. Each column of a table is stored separately, with a missing-value indicator (NULL) per column and dictionary compression; the data that queries work on resides in memory, with the disk serving as the durability medium.
Write-ahead log for durability. Every write goes through a log before being considered committed; periodic checkpoints limit the work to replay after an abrupt stop, whether it is a process termination, a power outage or a system shutdown.
Vectorized execution. Queries do not process rows one by one: they operate on batches of several thousand rows at a time, which reduces repeated per-row work and takes advantage of modern hardware.
Transactions. Each session can work in a transaction (START TRANSACTION, COMMIT, ROLLBACK), with serializable isolation that never blocks a reader waiting for a writer.

This manual stays at that level: it does not detail the internal organization of the engine (the internal layers, the binary formats) beyond what is useful for operating, configuring and administering it. Readers interested in the implementation will find that information in the project's technical documentation, separate from this manual.

1.5 Manual contents#

Introduction — this document
Installation — installing and starting MIRAJ, miraj-server and miraj-cli, building from source
Getting started — first step-by-step walkthrough: server, connection, table, data, queries
Data types — the supported SQL types
DDL language — databases, tables, views, indexes, constraints
DML language — INSERT, UPDATE, DELETE
SELECT queries — joins, aggregation, sorting, subqueries
SQL functions — string, number, date and control functions
Transactions and concurrency — isolation, locks, MVCC
Accounts and privileges — users, roles, GRANT/REVOKE
Server administration — configuration, security, monitoring, backups
Cluster and replication — Cluster edition, primary and secondaries
miraj-cli — SQL console reference
Client libraries — embedded API and miraj.dll wrappers
Error codes — reference of codes and messages
Known limitations — what MIRAJ does not do yet
miraj-migrate — migrating an existing SQL database to MIRAJ
Backup and restore — hot BACKUP / RESTORE, miraj-backup, SQL export miraj-dump