Operating

Configuration reference

Install · Security · systemd and Docker · Compatibility · Limits and defaults · MCP server · REST API

`port` server.port

Since v0.1.0

Port of the plain HTTP listener.

Default

3000

Effect

The port of the plain HTTP listener, which binds on server.bind_address. The value is a whole number from 0 to 65535; anything else is rejected when the file is read.

The listener exists only while server.http_enabled is true. The port must differ from server.tls_port, even while one of the two listeners is off, and the start is refused otherwise. While the MCP listener runs, mcp.port must differ from this port as well.

A port that another process holds makes the start fail with the bind error of the operating system, and so does a port below 1024 unless the host lets unprivileged users bind it. The packaged service runs as the unprivileged user luradb and its unit grants no capability for low ports.

Background

The REST API, the health check and, when switched on, the Swagger UI all answer on this port, so it is the one setting that decides where clients connect. A host often runs other services; change the port when 3000 is taken, or when a firewall rule or a proxy configuration expects a fixed port. Clients on the same host can use the Unix socket of server.unix_socket_path instead and need no port.

Referenced on

Install · Security · systemd and Docker · Troubleshooting · Limits and defaults · REST API

`http_enabled` server.http_enabled

Since v0.2.0

Starts the plain HTTP listener; at least one of HTTP and HTTPS must be on.

Default

true

Effect

With false, the server does not open the plain HTTP listener and logs HTTP listener disabled by config (server.http_enabled = false). at start. The Unix socket and the MCP listener are not affected.

At least one of this key and server.tls_enabled must be true. If both are false, the start is refused with invalid config: server.http_enabled and server.tls_enabled are both false — no listener would start. The port numbers are still compared while one listener is off, see server.port.

Background

Turn the plain listener off when clients must reach the server over HTTPS only, so that no cleartext port exists. Health checks and other tools then have to use the HTTPS port as well; /health answers there like on the plain port.

Referenced on

Security · Limits and defaults

`hello_enabled` server.hello_enabled

Since v0.1.0

Registers the root route / that answers with the hello message.

Default

truePackaged value false

Effect

With true, the server answers GET / with status 200 and a JSON body of the form {"message": "…"}, the text coming from server.hello_message. With false, the route does not exist; with authentication off, GET / then answers 404.

The route sits outside the authentication layer. It answers without an API key even while auth.enabled is on.

Background

The route is a plain “is something listening here” answer. /health is the endpoint for monitoring: it reports the version, the state of every data shard and the resource state. Leave the root route off unless you want a response that every client gets without a key.

Referenced on

Security · REST API

`hello_message` server.hello_message

Since v0.1.0

Response text of the root route.
Default: "Hello from LuraDB"
Effect: The text returned in the message field of the root route. Any string is accepted and no length is checked; the server escapes it for JSON, so quotes in the text are safe. The value is read only while server.hello_enabled is true.
Background: The text lets you tell instances apart, for example by environment name. The route answers without an API key, so the text is visible to every client that can reach the port; do not put anything in it that should not be public.
Referenced on: —

`unix_socket_path` server.unix_socket_path

Since v0.1.0

Unix domain socket for local clients. /run/luradb is created by systemd (RuntimeDirectory). Access: group luradb (fixed socket mode 0o660).

Default

not set (no socket)Packaged value "/run/luradb/luradb.sock"

Effect

When the key is set, the server also listens on a Unix domain socket at this path and serves the same API through it as on the TCP listeners. Without the key there is no socket. The socket comes in addition to the TCP listeners: server.http_enabled and server.tls_enabled must still not both be false.

The path must be absolute, and its directory must exist; the server does not create it. The start is refused with unix_socket_path must be absolute: … or parent directory of unix_socket_path does not exist: … otherwise. A file at the path that is not a socket also refuses the start (unix_socket_path exists and is not a socket: …) and is left untouched. A socket file left behind by an earlier run is removed and created again. The server sets the mode of the socket to 0660; the mode is not configurable. The owner and group are the account the server runs as. The socket file is removed again on an orderly shutdown.

Requests on the socket are authenticated like those on the TCP listeners: with an API key as Bearer token while auth.enabled is on. The exception are processes whose user ID is listed in auth.trusted_uids: the kernel reports the user ID of the connecting process to the server, and such a connection gets admin access without a key.

Background

A local client that uses the socket needs no TCP port, and who may connect is decided by file permissions. With trusted user IDs, local tools such as backup or monitoring scripts can work without an API key stored in a file.

The packaged service runs as user and group luradb and has systemd create /run/luradb with mode 0750 (RuntimeDirectory), which is why the packaged configuration places the socket there: members of the group luradb can reach the directory and, with mode 0660, the socket. A client in that group but with a user ID that is not trusted still has to send an API key.

Referenced on

Install · Security · systemd and Docker · Limits and defaults

`tls_enabled` server.tls_enabled

Since v0.2.0

Starts the native HTTPS listener, opt-in. Quickstart to enable: packaging/INSTALL.md "Enabling HTTPS".

Default

false

Effect

With true, the server terminates TLS itself: it opens an HTTPS listener on server.tls_port at server.bind_address, using the certificate and key from server.tls_cert_path and server.tls_key_path. The listener offers HTTP/2 and HTTP/1.1 and does not ask clients for a certificate. A TLS handshake that does not finish within 10 seconds is dropped.

The plain HTTP listener keeps running next to it unless server.http_enabled is false; the server does not redirect from one to the other. A plain HTTP request to the HTTPS port, or the other way round, fails at the connection.

The MCP listener shares the setting. With true and mcp.enabled, the listener on mcp.port serves HTTPS only, with the same certificate.

The certificate and the key are loaded once while the server starts. An unreadable or invalid file refuses the start with a message that names the key, such as cannot open server.tls_key_path '…': No such file or directory (os error 2) or server.tls_cert_path '…' contains no certificate. With false, the two paths are not read at all, and a missing file does no harm.

Background

TLS needs a certificate and a key that the operator provides. Native TLS lets a single host serve clients over HTTPS without a reverse proxy. Because the files are read only at start, a renewed certificate takes effect after a restart of the service, and a renewal tool needs a hook that restarts it. If you terminate TLS in a reverse proxy instead, leave this key off and see proxy.trusted_proxies for how the server treats the client address the proxy forwards.

Referenced on

Security · Limits and defaults · MCP server

`tls_port` server.tls_port

Since v0.2.0

Port of the HTTPS listener; must differ from the HTTP port.

Default

3443

Effect

The port of the HTTPS listener, which binds on server.bind_address. The value is a whole number from 0 to 65535; anything else is rejected when the file is read. The listener exists only while server.tls_enabled is true.

The port must differ from server.port, whether or not both listeners run. The start is refused otherwise with invalid config: server.tls_port (N) must differ from server.port (N). While mcp.enabled and TLS are both on, mcp.port must differ from this port too. A port held by another process makes the start fail with the bind error of the operating system.

Background

Change the port when it is taken, or when a firewall rule or a proxy expects a fixed port. Ports below 1024, such as 443, are not available to the unprivileged account of the packaged service unless the host allows unprivileged users to bind them.

Referenced on

Security · Troubleshooting · Limits and defaults

`tls_cert_path` server.tls_cert_path

Since v0.2.0

PEM certificate of the HTTPS listener, optionally with its chain.

Default

"/etc/luradb/tls/server.crt"

Effect

The PEM file with the server certificate. The file may hold the certificate chain: the server reads every certificate in it and presents them in the order they appear, so the server certificate must come first. The server reads the file once, while it starts, and only while server.tls_enabled is true.

A file that cannot be opened, cannot be parsed or holds no certificate refuses the start, with cannot open server.tls_cert_path '…', cannot parse server.tls_cert_path '…' or server.tls_cert_path '…' contains no certificate. A certificate that does not match the key of server.tls_key_path refuses it with invalid TLS certificate/key pair.

Background

The service account must be able to read the file. The package creates /etc/luradb/tls, owned by root with the group luradb and mode 0750, for the certificate and the key; the server never writes there. A certificate that is renewed in place is not picked up before the next start of the service.

Referenced on

Security · systemd and Docker · Limits and defaults

`tls_key_path` server.tls_key_path

Cap on the write-ahead log of each engine, the system store's included. Once its segments reach it, the shards whose records in the oldest segment are not in SSTables yet write them there, and the segment is deleted; a larger cap means fewer such writes and a longer recovery after a crash. At least 128 MiB. A number with a unit: B, kB, MB, GB, TB (powers of 1000) or KiB, MiB, GiB, TiB (powers of 1024), as in "512 MiB".

Default

"256 MiB"

Effect

Each engine (key-value, JSON, relational) keeps a write-ahead log, and so does the system store. A log is a directory of segment files of 64 MiB each. This key caps the segments of one log.

The value is a number with a unit, as in "256 MiB". The units are B, kB, MB, GB and TB (powers of 1000) and KiB, MiB, GiB and TiB (powers of 1024), in any case; the number may have decimals. The smallest allowed value is 128 MiB, which is two segments, so the segment to drop is never the one being written. A number without a unit, an unknown unit or a value below 128 MiB refuses the start with an invalid config: storage.wal_max_size … message.

Once a second the server looks at each log. When its closed segments plus one full segment reach the cap, the shards that still hold records of the oldest segment only in memory write them to SSTables, and the segment is deleted. A segment that has held records for five minutes is closed and dropped the same way, whatever the cap, so a quiet database does not keep records in its log for long. A log stays within about one segment of the cap.

Background

A write is confirmed once it is in the log, and the log is what recovery replays after a crash. A segment can only be deleted when every shard has its records in SSTables. A shard that rarely writes would keep old segments alive for a long time, so the cap makes such shards write their records out and lets the server delete the segment.

A larger cap means fewer of these early writes and a longer recovery after a crash, because more records sit in the log. A smaller cap, down to 128 MiB, keeps the log and the recovery short at the price of more early writes. Each log can use the cap plus about one segment of disk space, so the volumes of storage.wal_path, json.wal_path, rel.wal_path and storage.system_dir need room for that. A shard also writes its MemTable out on its own when it reaches lsm.memtable_size_threshold, which shortens the log without the cap.

The default of 256 MiB (four segments) suits most installations. Raise it on a host with sustained heavy writes and plenty of disk, lower it on a small volume.

Referenced on

Write path · Limits and defaults

`[resources]`

`disk_free_warn` resources.disk_free_warn

Since v0.5.1

Free space below which the server warns.

Default

"15% max 10 GB"

Effect

Once a second the server reads the free space of every volume that one of its data paths lies on: the SSTable and system directories, the directories of the page file, the write-ahead log and the value log, those of the JSON and relational engines while they are on, the backup directory while backups are on, and the log directory when log.path is set. Volumes that several paths share are watched once. “Free” is the space an unprivileged process can use, without the share reserved for root.

When the free space of a volume falls below this threshold, the state of the server changes to warning. The server logs Resources running short: disk <path> free … of …, threshold …. Nothing is refused yet; writes are refused below the block threshold. and repeats the line every 60 seconds while the state lasts. GET /health answers status: "degraded" with resources.disk_state: "warning", still with HTTP status 200. The metrics endpoint shows the free space per volume. Nothing is refused. The state returns to normal, with a log line, once every volume has been above the threshold for two readings in a row.

The value is a size, a percentage of the volume, or both. A size is a number with a unit: B, kB, MB, GB, TB (powers of 1000) or KiB, MiB, GiB, TiB (powers of 1024), in any case, as in "2 GB". A percentage is above 0 and up to 100, decimals allowed, as in "5%" or "2.5%". A percentage followed by max and a size, as in "15% max 10 GB", takes the smaller of the two. The server resolves the value once at start, separately for each volume, against the total size of that volume. A value in another form refuses the start with invalid config: resources.disk_free_warn (…) needs a size such as "2 GB", a percentage above 0 up to 100 such as "5%", or a percentage with a cap such as "15% max 10 GB".

For every volume, the resolved thresholds must satisfy disk_free_block <= disk_free_resume <= disk_free_warn, and the block threshold must be at least 64 MiB. Otherwise the start is refused with a message that lists the three resolved values in bytes.

Background

The warning is the early notice: it fires while nothing is wrong yet, so that monitoring, which can read the degraded status of /health, and the operator have time to add space or remove data before the server has to refuse writes (resources.disk_free_block). Choose a threshold that gives that time at the rate your data grows. A percentage with a cap suits both small and large volumes: with "20% max 50 GB", a 100 GB volume warns below 20 GB and a 1 TB volume below 50 GB, instead of at 200 GB.

Referenced on

Resource guard · Monitoring · Troubleshooting

`disk_free_block` resources.disk_free_block

Since v0.5.1

Free space below which the server refuses writes.

Default

"5% max 2 GB"

Effect

When the free space of any watched volume falls below this threshold, the server refuses writes. The volumes and the form of the value are described at resources.disk_free_warn. A refused write is answered with 507 Insufficient Storage, the header Retry-After: 5 and the body 507 Insufficient Storage: write blocked: disk space below threshold, retry in 5 s. The write is not applied. The server logs Writes refused: … as an error with the volume, its free space and the threshold, and repeats the line every 60 seconds while the state lasts.

Everything that writes is refused: puts, deletes, bulk requests, new domains, tables and indexes, and new backups. The exception is a new backup whose directory (backup.dir) lies on a volume that is above its warn threshold, as long as memory is not the reason for the block. Three groups go on: reads, GET /health and the downloads of existing backups; sign-in and the management of accounts and keys, that is every request under /store-api/auth/; and the deletion of a backup, which frees space. Deleting keys does not free space, because a delete is a write and is refused too.

The TTL sweeper (ttl_sweeper.enabled) writes no tombstones while writes are refused. A compaction or a value-log cleanup waits whenever its volume has less room than its inputs or its live values take, blocked or not. The state ends as described at resources.disk_free_resume.

The threshold must be at least 64 MiB on every volume and may not exceed the resume threshold; the start is refused otherwise, see resources.disk_free_warn.

Background

A server that fills its disk cannot finish the work that is already under way: a flush needs room for its SSTable, and a failed write of a data file can force the server to stop. The block threshold leaves free space for that work and for the sign-in records, which still go through below the threshold, and it gives clients a defined answer, 507 with Retry-After, instead of errors from a full disk.

Set the threshold above the space the server may still need after it stops accepting writes: the SSTables for the MemTables in memory (lsm.memtable_size_threshold per engine and shard) and the output of a compaction that is running, which can be as large as its inputs. The readings come once a second, so a fast writer can use up a good part of the margin before the state changes.

Referenced on

Resource guard · Troubleshooting · Limits and defaults · Status codes

`disk_free_resume` resources.disk_free_resume

Since v0.5.1

Free space each volume needs before refused writes resume.

Default

"10% max 4 GB"

Effect

The free space that every watched volume needs before refused writes are accepted again. The form of the value is described at resources.disk_free_warn. While any volume is below this threshold after a block (resources.disk_free_block), the state stays blocked: the server keeps answering writes with 507 and logs Writes refused: …, naming the volumes that hold the block.

When every volume has been above the threshold for two consecutive readings, which come once a second, and memory is below its resume level, the server logs Writes are accepted again and moves to the warning state; if a volume is still below the warn threshold, the line adds Still low: …. Two more readings above the warn threshold bring it back to normal (resources.disk_free_warn).

The threshold must lie between the block and the warn threshold on every volume: disk_free_block <= disk_free_resume <= disk_free_warn. Otherwise the start is refused, see resources.disk_free_warn.

Background

The gap between the block and the resume threshold keeps the server from switching between accepting and refusing writes every second. Without a gap, the first writes after a block would fill the volume past the block threshold again. Choose a resume threshold that leaves room for a useful stretch of writing. You reach it by freeing space, for example by deleting old backups, which is allowed while writes are refused.

Referenced on

Resource guard · Troubleshooting

`memory_budget` resources.memory_budget

Since v0.5.1

Anonymous memory the server may use: a percentage of the host's memory, or of its cgroup's memory.max when that is lower, or a size; at least 256 MiB. Writes warn from 80 %, are refused from 95 % and resume below 90 % of it.

Default

Data shards, each a thread with its own storage engines that writes the domains assigned to it. The data directory layout depends on it: 0 keeps the count an existing data directory was written with, and gives a new one cores / 4, 1 to 8. A set count that differs from the one the data was written with refuses the start; luradb --migrate-shards N changes the count of a data directory while the server is stopped.

Default

0

Effect

The number of data shards. A shard is one thread with its own storage engines, and it writes the domains assigned to it. The value is a whole number from 0 to 65535.

0 is automatic. A data directory that already exists keeps the count it was written with, also after an upgrade or a move to a host with another core count; a directory laid out without shard directories counts as one shard. A new data directory gets a quarter of the cores, at least 1 and at most 8. When the host would pick another count than the one stored, the start logs a warning that names the migration command.

A value above 0 is used as given, but only on a data directory written with that count. A different count refuses the start with shard count changed (stored N, configured M) and names luradb --migrate-shards M. The first start records the count. Only the migration tool changes it, on a stopped server.

Every domain lives on exactly one shard, chosen from the name of the domain and the same for all three engines. The writes of a domain run on the thread of its shard, so domains that fall on the same shard take turns. Reads do not wait for the thread of the shard: point reads run on the connection thread and longer reads on the reader pool, see multicore.reader_threads.

Each shard adds a thread. The block cache of each engine and the buffer pool are split evenly across the shards, but the MemTable threshold applies per engine and shard, so MemTable memory grows with the count. The automatic multicore.reader_threads takes the cores that are left after the shards and the multicore.frontend_workers.

Background

The shard count decides which thread owns which domain, so it is part of the layout of the data and not a knob to turn at run time. Data written for three shards cannot be served by a server that routes for two without moving it first. The server therefore refuses a mismatch instead of rerouting silently, and the count changes only through an offline tool that rewrites the data directory.

More shards let more domains write at the same time. They do not help a single busy domain, because its writes stay on one core, and they use cores and memory that readers could use. Leave the key at 0 unless the automatic count does not fit the host, for example when the writes are spread over many domains on a large host, or when a small host should keep its cores for readers.

Referenced on

Upgrading · Multicore · Troubleshooting · Compatibility

`shard_queue_capacity` multicore.shard_queue_capacity

Since v0.5.1

Requests one data shard takes at once, running or waiting; further requests are answered with 503 and Retry-After: 1. At least 1.

Default

1024

Effect

The number of requests that one data shard takes at the same time, running or waiting. Every shard has its own limit. A request counts from the moment the frontend hands it to the shard until it is answered. This covers the writes of the shard’s domains and the other requests that run on the shard’s thread; reads that run on the reader pool or on the frontend do not count (see multicore.reader_queue_capacity).

A request that finds the limit reached is not processed. It is answered at once with 503 Service Unavailable, the header Retry-After: 1 and the body 503 Service Unavailable: the server is overloaded, retry later, and the client may send it again. The value must be at least 1; the start is refused with invalid config: multicore.shard_queue_capacity (0) must be at least 1 otherwise. The start log shows it in the line N cores: …; shard queue capacity: N.

Writes without a domain, such as the management of accounts, run on the control-plane thread and are not limited by this key. The number also adds to the queue for wake-ups from other threads that each shard and the control-plane thread allocate, together with storage.wal_queue_capacity.

Background

Every domain lives on one shard and its writes run one after another on the thread of that shard. When writes arrive faster than the shard completes them, the limit stops the queue from growing without bound: the server sheds the excess quickly with a status that tells clients to retry, instead of letting requests wait ever longer in memory. A burst on one domain fills the lane of that shard only; domains on the other shards go on.

Raise the value if bursts of concurrent writes to a few domains produce 503 answers while the CPU has room. If the lane is full for long, the shard itself is the bottleneck, and a longer queue only moves the waiting from the client to the server. In that case, spread the writes over more domains or add shards (multicore.shards).

Referenced on

Multicore · Troubleshooting · Limits and defaults · Status codes

`reader_threads` multicore.reader_threads

Since v0.5.1

Threads that serve read requests next to the data shards: 0 is automatic (cores minus 2, minus the data shards and the frontend threads, at least 1), otherwise at most the number of cores.

Default

0

Effect

The number of threads of the reader pool. The pool runs every read that is not a lookup of a single key, document or row, which the frontend answers itself: key listings, counts, document searches, SQL requests, metrics, streams such as the watch endpoint, and downloads. It also takes over a single-item read that would have to wait for the disk, which the frontend then does not serve itself. It reads the same engines as the data shards and runs on its own threads, so reads do not wait for the thread of a shard.

0 is automatic: the cores minus two, minus the data shards and the frontend workers, at least 1. The start log shows the result in the line N cores: M frontend workers, K data shards, R reader threads; …. An explicit value must not exceed the number of cores the process can use; the start is refused with invalid config: multicore.reader_threads (…) must be 0 (auto) or 1 to N (available cores) otherwise. The server does not check that the frontend workers, the data shards and the reader threads together fit the cores.

Background

Reads scale with these threads, writes with the shards. A read-heavy installation gets more from additional reader threads than from additional shards. On a host that is busy with other work, set a value that fits the cores you want to give the database; the automatic value counts all cores of the host. If clients receive 503 answers on reads, look at multicore.reader_queue_capacity and at whether the pool has enough threads for the load.

Referenced on

Multicore · Troubleshooting · Limits and defaults

Multicore · Write path

`max_key_length` lsm.max_key_length

Since v0.1.0

Longest stored key in bytes, including the internal domain prefix.

Default

256

Effect

The limit, in bytes, for the keys of the key-value engine as the engine stores them. A stored key is the user key with a prefix of 19 bytes in front of it (d:, 16 hexadecimal digits that identify the domain, and :). The value must not exceed 100663296 bytes (96 MiB), the largest field that the recovery of the write-ahead log reads; the start is refused with invalid config: lsm.max_key_length (…) exceeds the WAL recovery field cap (100663296 bytes) — writes this large could never be recovered otherwise.

In v0.5.1 the engine applies the limit to the batches of operations it writes and to its own records, but not to the single-key writes of the REST API. A bulk delete by prefix (DELETE /store-api/kv/{domain}/keys?prefix=…) is such a batch. If one of the stored keys it would remove is longer than the limit, the request is answered with 500 and a body such as Key length 269 exceeds maximum of 256 bytes, and no key is deleted. A put or a single delete of a key is not checked against this key. A put is limited by domains.max_user_key_length, which answers a longer key with 400 Bad Request: Key length N exceeds maximum of M bytes.

The two limits therefore interact. If domains.max_user_key_length plus 19 is larger than this key, keys longer than this key minus 19 bytes can be written but not removed by a bulk delete by prefix. To keep the bulk delete working for every key you accept, set this key to at least domains.max_user_key_length plus 19.

The JSON and relational engines have their own limits (json.lsm.max_key_length and rel.lsm.max_key_length), and the system store uses a built-in one.

Background

A key is stored in every MemTable entry, every write-ahead log record and every SSTable entry, together with an 8-byte timestamp per version, so the length of the keys is paid for in memory and on disk. The limit guards the engine against keys of unreasonable size. Keep it as small as your keys allow, and raise it together with domains.max_user_key_length if you need longer keys.

Referenced on

Limits and defaults · Status codes · Key-value

`max_value_size` lsm.max_value_size

Since v0.1.0

Largest value in bytes; larger writes are rejected.

Default

524288

Effect

The largest value, in bytes, that the engine accepts on the paths where it checks the size. The value must not exceed 100663296 bytes (96 MiB), the largest field that the recovery of the write-ahead log reads; the start is refused with invalid config: lsm.max_value_size (…) exceeds the WAL recovery field cap (100663296 bytes) — writes this large could never be recovered otherwise.

In v0.5.1 the REST API does not apply the limit to the values of single keys. With the key set to 1000, a put of a 5000-byte value to a key-value domain is answered with 200. What limits such a put is the size of the request body: the server rejects a body above 2 MiB (2097152 bytes) with 413 and the body Failed to buffer the request body: length limit exceeded. The engine’s own check, which answers Value length N exceeds maximum of M bytes, applies to the engine’s batches and to its own records, and the value of a put to a key-value domain never reaches it.

The JSON engine and the relational engine have limits of their own (json.lsm.max_value_size and rel.max_row_size), and the system store uses a built-in one.

Background

The key is the size limit that the engine of the key-value store carries. Its upper bound exists so that no value can be written that the recovery of the write-ahead log would refuse to read after a crash. Do not rely on the key to cap the size of values in this release; the request limit of 2 MiB is the effective ceiling for a value. If you need a smaller ceiling, enforce it in the client or in a reverse proxy in front of the server.

Referenced on

Limits and defaults · Key-value

`flush_check_interval_ms` lsm.flush_check_interval_ms

Since v0.1.0

How often, in milliseconds, the flush loop checks for a full MemTable.

Default

100

Effect

The pause, in milliseconds, between two turns of the flush loop of a shard. In each turn the loop writes the oldest frozen MemTable of the shard to a new SSTable at level 0, if there is one, and then sleeps for this long. A MemTable is frozen by the write that follows the moment it reaches lsm.memtable_size_threshold. After a failed flush the loop waits for lsm.compaction_check_interval_ms instead. The loop writes at most one MemTable per turn; the shutdown of the server and the steps that need all data in SSTables (the cleanup of the value log, the write-ahead log cap of storage.wal_max_size) flush MemTables on their own.

The value is a whole number of milliseconds and is not checked at start. Do not use 0: with 0 the data shard threads ran at full load in a test of v0.5.1, and the start did not finish. The start log ended at the per-shard memory lines, with no data shard(s) ready and no listener.

Background

A frozen MemTable stays in memory, and stays in the write-ahead log, until the loop reaches it. A short pause gets data into SSTables quickly and keeps the memory of frozen MemTables and the log short, at the price of more wake-ups of an idle shard. With the default MemTable size, one flush per turn is an upper bound of a few tens of MiB per second and shard for the loop; if you raise the write rate beyond what one MemTable per turn can absorb, lower the pause or enlarge the MemTable. The pause is rarely the first setting to look at.

Referenced on

Write path

Since v0.1.0

Size factor between consecutive levels (level 2 holds 10 times level 1).
Default: 10
Effect: The factor by which the size limit grows from one level to the next. Level 1 is limited by compaction.l1_max_size; level n from 2 on is limited to that value times this factor raised to the power n - 1. With a factor of 4 and a level-1 limit of 50 MiB, levels 2 and 3 are limited to 200 MiB and 800 MiB. A level is compacted into the next one when its total size reaches its limit. The calculation saturates instead of overflowing, so a very large value does not wrap around. The value is a whole number and is not checked at start.
Background: The factor shapes the tree: with a larger factor, the same amount of data spreads over fewer levels, and each level holds more before it is pushed down. With a smaller factor, there are more levels with smaller steps between them. Change it only together with compaction.l1_max_size and after you have measured the compaction work for your own data volume.
Referenced on: Write path

Referenced on

Domains and engines · JSON documents

`wal_path` json.wal_path

Since v0.1.0

Write-ahead log; relative paths resolve against the working directory. A directory of segment files the server creates, writes and deletes; never change anything in it by hand. The path may be a symlink, the segments then lie at its target. A log file of an earlier LuraDB version at the path becomes such a directory on the first start; an earlier version does not start on it.

Default

"luradb_json.wal"

Effect

The directory of the write-ahead log of the JSON engine. It holds segment files of 64 MiB each, named 00000001.wal, 00000002.wal and so on, which the server creates, writes and deletes; nothing in it should be changed by hand. All data shards of the JSON engine share this one log, so unlike the value log and the SSTables it is not placed in a shard_<k> directory. A log file of an earlier LuraDB version at the path becomes such a directory on the first start, and an earlier version does not start on it.

The path may be a symbolic link, and the segments then lie at its target. A relative path resolves against the working directory of the server process; the packaged service sets that to /var/lib/luradb, so the packaged luradb_json.wal is /var/lib/luradb/luradb_json.wal. The parent directory is created at start.

No two data paths may resolve to the same location (symbolic links resolved). In a test of v0.5.1, setting this key to the value of storage.wal_path refused the start with invalid config: storage.wal_path and json.wal_path resolve to the same location '…'. The check is skipped while json.enabled is false. How much of the log the server keeps is set by storage.wal_max_size, which caps each engine’s log.

Background

A write to a JSON domain is confirmed once it is in this log, and recovery after a crash replays what the SSTables do not yet hold. The write waits for the log to reach the disk, so the latency of the volume sets the lower bound for the latency of document writes. The storage thread of the server writes the logs of all engines and batches concurrent writes into one fsync per log. Place the log on a volume with room for storage.wal_max_size plus one segment.

Referenced on

Write path · systemd and Docker · Limits and defaults

`vlog_path` json.vlog_path

Since v0.1.0

Value log for large documents.

Default

"luradb_json.vlog"

Effect

The value log of the JSON engine. A stored document of 1,024 bytes or more is appended to it, and the SSTables keep only a pointer to it. The threshold is built in: the JSON engine does not use lsm.vlog_inline_threshold. A stored document is a little larger than the JSON that the client sent, because a version number and an incarnation id are stored with it. Each data shard has its own file: the server inserts a directory shard_<k> before the file name, so a path /var/lib/luradb/luradb_json.vlog becomes /var/lib/luradb/shard_0/luradb_json.vlog for shard 0. A relative path resolves against the working directory of the server process (under the packaged service, /var/lib/luradb).

When the value log is cleaned, the live values move into a new generation whose file name is the configured name with .2 appended, then .3, and so on. No other data path may equal this name followed by a dot and digits; the start is refused if one does. The cleanup runs with the built-in settings of the janitor, not with the janitor section of the file, which applies to the key-value engine.

No two data paths may resolve to the same location. The check is skipped while json.enabled is false. The key-value engine and the relational engine have their own value logs, storage.vlog_path and rel.vlog_path.

Background

Keeping large documents out of the SSTables means that a compaction rewrites keys and pointers, not the documents. The price is that overwritten and deleted documents stay in the log as dead space until the cleanup rewrites it, so the volume needs room for the data plus the dead space that builds up between cleanups. The cleanup waits while the volume has less room than the live values take.

Referenced on

Write path · systemd and Docker · Limits and defaults

`sstable_dir` json.sstable_dir

Since v0.1.0

SSTable directory.

Default

"luradb_json_sstables"

Effect

The directory of the SSTables of the JSON engine. Each data shard keeps its files in a subdirectory shard_<k> of it, with the files sstable_<number>.sst and a MANIFEST that lists them and their levels. The server creates the directory at start. A relative path resolves against the working directory of the server process (under the packaged service, /var/lib/luradb).

A flush of the MemTable of the JSON engine adds a file at level 0, and compactions merge files into the levels below. The JSON engine runs these with the built-in defaults (a flush at a MemTable of 4 MiB, a compaction at four level-0 files, level 1 at 100 MiB, a factor of 10 between levels, SSTables of at most 64 MiB), not with the lsm and compaction sections of the file, which apply to the key-value engine only. Documents of 1,024 bytes or more are not in the SSTables but in the value log (json.vlog_path).

The server does not move data when the path changes. A start with another path opens an empty set of SSTables there, and the data in the old directory is not read. No two data paths may resolve to the same location; the check is skipped while json.enabled is false.

Background

A compaction writes its output before it deletes its inputs, so the volume needs free room of at least the size of the inputs of the next compaction; the server holds a compaction back and logs Compaction of level … waits for disk space while it has less. Plan the volume with headroom beyond the data size, and see resources.disk_free_warn for the thresholds at which the server warns and refuses writes.

Referenced on

Write path · systemd and Docker · Limits and defaults

`bulk_body_limit_bytes` json.bulk_body_limit_bytes

Since v0.1.0

`enabled` rel.enabled

Since v0.1.0

Starts the relational engine.

Default

true

Effect

With true, the server runs the relational engine (LuraSQL): it opens its write-ahead log, value log and SSTables (rel.wal_path, rel.vlog_path, rel.sstable_dir), creates a relational domain named default at start, and serves the /store-api/rel/… endpoints. The engine runs on a storage instance of its own, so SQL work does not share MemTables, caches or compactions with the other engines.

With false, no relational instance starts and the log says Relational engine disabled by config.. The whole relational REST surface is then absent: in a test of v0.5.1, GET /store-api/rel/domains and POST /store-api/rel/default/sql were answered with an empty 404, although the OpenAPI document lists 503 for the disabled engine on these endpoints. No relational files were created. The other engines keep working, with these exceptions:

A backup of scope rel or rel:<domain> fails with rel_engine_disabled; scope all leaves relational data out.
The tool list_domains of the MCP server names the engine under unavailable_engines.

Data already written stays in the files. While the engine is off, the paths of its files are not checked against the other data paths, but its limits (rel.max_tables_per_domain, rel.max_row_size, rel.max_limit, rel.max_sort_rows and rel.lsm.max_key_length) are still validated at start.

Background

Switch the engine off if the installation runs no SQL. It saves what the engine reserves: two MemTables of 4 MiB per shard, a block cache of 64 MiB (divided across the shards), and one write-ahead log that the storage thread has to write. The reservation is part of the fixed memory that the server compares with resources.memory_budget.

Referenced on

Domains and engines · Troubleshooting · LuraSQL

`wal_path` rel.wal_path

Since v0.1.0

Default

"luradb_rel.wal"

Effect

The directory of the write-ahead log of the relational engine. It holds segment files of 64 MiB each, named 00000001.wal, 00000002.wal and so on, which the server creates, writes and deletes; nothing in it should be changed by hand. All data shards of the relational engine share this one log, so unlike the value log and the SSTables it is not placed in a shard_<k> directory. A log file of an earlier LuraDB version at the path becomes such a directory on the first start, and an earlier version does not start on it.

The path may be a symbolic link, and the segments then lie at its target. A relative path resolves against the working directory of the server process; the packaged service sets that to /var/lib/luradb, so the packaged luradb_rel.wal is /var/lib/luradb/luradb_rel.wal. The parent directory is created at start.

No two data paths may resolve to the same location (symbolic links resolved); the start is refused with invalid config: … resolve to the same location '…' otherwise. The check is skipped while rel.enabled is false. How much of the log the server keeps is set by storage.wal_max_size, which caps each engine’s log.

Background

A DDL or DML statement is confirmed once its changes are in this log, and recovery after a crash replays what the SSTables do not yet hold. The statement waits for the log to reach the disk, so the latency of the volume sets the lower bound for the latency of writes. The logs of the other engines are storage.wal_path and json.wal_path. Place the log on a volume with room for storage.wal_max_size plus one segment.

Referenced on

Write path · systemd and Docker · Limits and defaults

`vlog_path` rel.vlog_path

Since v0.1.0

Value log for large rows.

Default

"luradb_rel.vlog"

Effect

The value log of the relational engine. An encoded row of 1,024 bytes or more is appended to it, and the SSTables keep only a pointer to it. The threshold is built in: the relational engine does not use lsm.vlog_inline_threshold. Each data shard has its own file: the server inserts a directory shard_<k> before the file name, so a path /var/lib/luradb/luradb_rel.vlog becomes /var/lib/luradb/shard_0/luradb_rel.vlog for shard 0. A relative path resolves against the working directory of the server process (under the packaged service, /var/lib/luradb).

When the value log is cleaned, the live rows move into a new generation whose file name is the configured name with .2 appended, then .3, and so on. No other data path may equal this name followed by a dot and digits; the start is refused if one does. The cleanup runs with the built-in settings of the janitor, not with the janitor section of the file, which applies to the key-value engine.

No two data paths may resolve to the same location. The check is skipped while rel.enabled is false. The key-value engine and the JSON engine have their own value logs, storage.vlog_path and json.vlog_path.

Background

Keeping large rows out of the SSTables means that a compaction rewrites keys and pointers, not the rows. The price is that overwritten and deleted rows stay in the log as dead space until the cleanup rewrites it, so the volume needs room for the data plus the dead space that builds up between cleanups. The cleanup waits while the volume has less room than the live values take.

Referenced on

Since v0.1.0

Most rows an ORDER BY sorts or an unindexed join scans; more fail with 400. Rows up to this limit are held in memory while sorting.

Default

100000

Effect

The most rows that the server collects in memory to sort a result, and the most rows that an unindexed join (rel.allow_unindexed_joins) may scan in one statement.

An ORDER BY needs the sort buffer unless the order is free. It is free when a single column is sorted and the chosen access path already delivers the rows in that order: the primary key, or a NOT NULL column that has an index. Otherwise the server reads all rows that pass the WHERE clause into memory, sorts them, and only then applies OFFSET and LIMIT. If more rows than the limit pass, the statement fails with 400 and sort buffer of 4 rows exceeds maximum of 3; narrow the result with WHERE/LIMIT or add a matching index, which is the answer in a test of v0.5.1 with the key set to 3 and ten rows. A LIMIT does not help, because the sort comes first; a WHERE clause that matches fewer rows, or an index on the sorted column, does.

For an unindexed join the key bounds the rows scanned in the right-hand table, counted over the whole statement: unindexed join fallback scan visited 5 rows, exceeding the limit of 4; add an index or narrow the result.

The value must be at least 1; 0 refuses the start with invalid config: rel.max_sort_rows (0) must be at least 1. The check runs even while rel.enabled is false.

Background

The server sorts in memory and does not spill to disk, so the sort buffer is the memory cost of an unindexed ORDER BY: the rows are held decoded, and a wide row costs more than a narrow one. The cap turns a sort that would not fit into an error at a known size instead of a slow or failed server. Prefer an index on the columns you sort by; raise the cap only if you sort larger results regularly and the host has the memory for them.

Referenced on

Limits and defaults · LuraSQL

`allow_unindexed_joins` rel.allow_unindexed_joins

Since v0.1.0

Lets a join on an unindexed column scan the table per row instead of failing with 400.

Default

false

Effect

Decides what a LEFT JOIN does when the column of the joined table in its ON clause is neither the primary key nor indexed.

With false, such a join is refused with 400 and a hint with the statement that fixes it, such as join column 'u.tid' is neither the primary key nor indexed; CREATE INDEX <name> ON u (tid). A join on a primary key or an indexed column looks up the matching rows directly. The check also applies when a view that contains such a join is created.

With true, the server instead scans the joined table once for each row of the left side. The scan is bounded: all rows visited by such scans in one statement count together against rel.max_sort_rows, and a statement that exceeds it fails with 400 and unindexed join fallback scan visited 5 rows, exceeding the limit of 4; add an index or narrow the result. In a test of v0.5.1 with a left table of three rows and a right table of three rows, the join succeeded with the default cap and failed with the key set to 4.

Background

An unindexed join costs about the number of left rows times the number of right rows, so it is fast on tiny tables and slow on large ones. The default refuses it so that a missing index shows up as an error you can fix instead of as a statement that gets slower as the data grows. Switch it on for development or for tables that stay small, and create an index for anything else.

Referenced on

LuraSQL

`import_body_limit_bytes` rel.import_body_limit_bytes

Since v0.4.0

Body-size cap for POST .../tables/from-file.

Default

67108864

Effect

The largest request body, in bytes, that POST /store-api/rel/{domain}/tables/from-file accepts. The endpoint takes a CSV or TSV file and creates a table from it; the file is read into memory as a whole before the table is created. A larger body is refused with 413 and Failed to buffer the request body: length limit exceeded; in a test of v0.5.1 with the key set to 100, a file of 169 bytes was refused and one of 20 bytes created a table with four rows. The other relational endpoints take bodies of up to 2 MiB; the key does not change that.

The import counts as one write of the rate limit of the domain (rate_limit.default_write_iops). Each row of the file then goes through the normal write path, so rel.max_row_size and rel.lsm.max_key_length apply to it; a row that fails is listed under errors in the 201 answer and does not stop the import. The server does not check the value at start.

Background

The limit exists because the body is held in memory while the file is parsed and imported, so several concurrent imports add up. The default of 64 MiB equals the limit for JSON bulk imports (json.bulk_body_limit_bytes). Lower it on a small host; for larger files, split them into several requests or raise the value.

Referenced on

Consistency and conditional writes · Limits and defaults · Status codes · LuraSQL

`[rel.lsm]`

`max_key_length` rel.lsm.max_key_length

Since v0.1.0

Since v0.1.0

Rotation of the log files: none, daily or hourly; needs a log path.

Default

"daily"

Effect

When the server starts a new log file. daily starts one at midnight UTC, hourly at the full hour UTC. The files are named luradb.log.<date> and luradb.log.<date>-<hour>; in a test of v0.5.1 at 20:13 UTC, daily wrote luradb.log.2026-11-03 and hourly wrote luradb.log.2026-11-03-20. Old files are not touched by the rotation; log.retention_days deletes them.

Every other value, including none, writes one file luradb.log that grows without bound. The value is not checked: in a test, weekly started the server and wrote luradb.log, so a misspelled value silently turns the rotation off. With log.path not set, the key has no effect.

The file for the current period is chosen when the server writes its first line of that period, and the server appends to a file that already exists, so a restart within the period continues the same file.

Background

Daily rotation suits most installations: a file is one day of log, and removing old days is a matter of log.retention_days. Choose hourly when a day of log is too large to handle, for example on a server with log.level set to verbose. Choose none only if an external tool rotates the file.

Referenced on

Monitoring

`retention_days` log.retention_days

Since v0.1.0

Days to keep rotated log files; 0 keeps them forever.

Default

30

Effect

The age, in days, after which the server deletes a log file. A background task looks at the log directory (log.path) and deletes every file whose name begins with luradb.log and whose last modification is more than this many days ago. Other files in the directory are left alone. With 0 nothing is deleted.

The task runs only when a log path is set and the value is above 0. It does not run at start: its first pass comes 24 hours after the process started, and then it repeats every 24 hours of running time. A server that is restarted more often than once a day therefore never deletes anything. The age is the modification time, not the date in the file name, so the file of the current period is never old enough while the server writes to it; with log.rotation set to none the single file is never deleted.

The key has no effect when the log goes to standard output.

Background

Rotated files accumulate unless something deletes them. The task deletes by age only, with no regard to the number or the size of the files, so choose the age from the amount of log that your log.level and rotation produce and from the space of the volume. Lower the value on a small volume, raise it if you have to keep logs longer, and use 0 if an external tool manages the files. A server that is restarted daily needs such a tool, because the first pass comes only after a day of running time.

Referenced on

Monitoring

`http_access` log.http_access

Since v0.3.0

Since v0.5.1

Offers only the tools that read; set to false to also offer the tools that write keys, documents and rows.

Default

true

Effect

With true, the MCP server offers the 17 tools that only read: whoami, list_domains, describe_domain, metrics (admin keys only), list_tables, describe_table, list_views, list_json_indexes, health, kv_get, kv_scan, kv_count, json_get, json_list, json_search, json_count and sql_query. sql_query runs one SELECT and refuses every other statement. The tools are marked as read-only in their annotations.

With false, six tools are added that change data: kv_put, kv_delete, kv_set_null, json_put, json_delete and sql_execute, which runs one INSERT, UPDATE or DELETE. They are marked as destructive. In a test of v0.5.1, the listing had 17 tools with true and 23 with false. A tool that is not offered is not only hidden: calling it returns the error tool '…' is not available. A statement sent to the wrong SQL tool is refused with a hint, for example this statement does not belong to this tool; use sql_query.

The switch narrows what MCP offers; it does not widen the rights of a key. A write needs both the tool and a key with the permission to write the domain, and the rate limits and the other limits of the REST API apply to every call. The tools that create structure are switched by mcp.allow_ddl, and only when this key is false. No tool deletes a domain, a table, a view or an index.

Background

An assistant or an agent that explores data can do harm with a wrong or a manipulated instruction. With true, no MCP tool can change data, whatever the client sends and whatever key it holds. That is the setting for a server that is queried, not edited, through MCP. Switch to false only for clients you trust with writes, and give them a key that holds a permission on the domains they need and nothing more.

Referenced on

MCP server · MCP with Claude

`allow_ddl` mcp.allow_ddl

Since v0.5.1

Also offers the tools that create domains, tables, views and indexes; only with read_only = false. No tool deletes a domain, table, view or index.

Default

false

Effect

Adds the three tools that create structure to what the MCP server offers: create_domain (a domain of the engine kv, json or rel; admin keys only), create_json_index (an index on a field of a JSON domain) and sql_ddl, which runs one CREATE TABLE, CREATE INDEX, CREATE VIEW or ALTER TABLE … ADD COLUMN, RENAME COLUMN or RENAME TO. They are marked as not read-only; sql_ddl is marked as destructive, since a rename breaks clients as a drop would. In a test of v0.5.1 with both keys set, the listing had 26 tools, three more than with mcp.read_only alone set to false.

No tool drops anything. sql_ddl refuses DROP TABLE, DROP INDEX, DROP VIEW and ALTER TABLE … DROP COLUMN before they reach the SQL route, with dropping a table, an index or a view is not available over MCP or dropping a column is not available over MCP, whatever the permission of the key. Deleting a domain, an index or a table needs the REST API.

The key has an effect only while mcp.read_only is false. With read_only still true, the server starts and logs the warning mcp.allow_ddl has no effect while mcp.read_only is true. The rights of the key apply as for every call: sql_ddl needs the Ddl permission on the domain, and create_domain an admin key.

Background

Structure changes are a different risk from data changes: a new table or a renamed column changes what other clients see. The switch lets you allow an assistant to write rows without letting it change the schema, which is why it is off by default even for a server with read_only = false. Switch it on for development or for a controlled setup where the assistant builds tables, and keep the rights of its key narrow.

Referenced on

MCP server · MCP with Claude

Since v0.1.0

Size in bytes of each shared-memory data segment. Two segments of this size plus one copy per rebuild are held in memory.

Default

268435456

Effect

The size, in bytes, of each of the two data segments in which the server publishes its snapshot of the key-value data. The server alternates between the two: it writes a new snapshot into the one that is not being read and then switches. The value must be at least 4096; smaller values refuse the start with invalid config: shm.data_buffer_size (100) must be at least 4096. The check runs even while shm.enabled is false.

The snapshot holds, for every active key-value domain in the order of the domain names, the keys, the inline values and an overhead of 64 bytes per entry. The server fills it only up to 7/8 of this size. When the data does not fit, the snapshot ends in the middle of a domain and leaves out the domains after it. The snapshot is published that way and the server logs a warning, SHM snapshot truncated in domain '…' (N later domain(s) omitted): accumulated size exceeded budget of … bytes (buffer …). A client then sees only part of the data. If the serialized snapshot is still too large for the segment, the publish fails and the server logs SHM snapshot publish failed: ….

The segments are created at their full size, but the server does not fill them; pages become resident as the snapshot is written. The server counts three buffers (the two segments and the copy made while a snapshot is rebuilt) toward its fixed memory (resources.memory_budget). The 4 MiB rings of each registered client come on top and do not depend on this key.

Background

The snapshot has to hold all inline key-value data that clients want to read, so size the buffer from your data: the sum of keys and inline values (lsm.vlog_inline_threshold) over all key-value domains, plus 64 bytes per key, with a margin of one eighth and room to grow. The default of 256 MiB is a ceiling, not an allocation. Raise it if the warning about a truncated snapshot appears; lower it to cap the memory that shared memory may use.

Referenced on

Write path · Limits and defaults

`registration_socket_path` shm.registration_socket_path

Since v0.1.0

Unix socket where SHM clients register; {instance_id} is replaced. It must differ from the Unix socket of the server section.

Default

"/run/luradb/{instance_id}.sock"

Effect

The Unix socket at which local clients register for shared memory. The text {instance_id} in the path is replaced by shm.instance_id; with the defaults the socket is /run/luradb/0.sock. A client connects, sends the line REGISTER, and receives OK <client id> <segment names> with the write end of a pipe attached (to wake the server after a command), or ERR unauthorized. The socket stays open as the sign of life of the client: when it closes, the server removes the segments of the client.

With auth.enabled on, only a process whose user ID is in auth.trusted_uids is accepted; the server reads the user ID from the connection, so a client cannot claim another one. In a test of v0.5.1, a process that was not listed got ERR unauthorized and a listed one got OK 1 /luradb_<id>_cmd_1 … with the four segment names of its channel. With authentication off, every process that can open the socket may register.

The server creates the socket with the mode 0660 when it starts, replaces a socket file left by an earlier run, and removes it when it stops. Unlike the socket of server.unix_socket_path, whose directory must exist, it creates the missing directory of this path; if that fails, the start stops with Error: create registration socket directory /run/luradb. The path must differ from the REST socket: the start is refused with invalid config: shm.registration_socket_path ('…') equals server.unix_socket_path — SHM clients could not register; use a different path. The check runs only while shm.enabled is true.

Background

Registration is separate from the REST socket because it speaks a different protocol: a line of text, then file descriptors, then rings of shared memory. A separate socket also makes the trust rule simple: the shared-memory channel has no API key, so the user ID of the connecting process is the only credential. The packaged service creates /run/luradb with the mode 0750 for the group luradb, which is where the default path puts the socket.

Referenced on

Write path · Limits and defaults

`snapshot_interval_ms` shm.snapshot_interval_ms

Since v0.1.0

How often, in milliseconds, the snapshot is checked for changes; it is rebuilt only after a change, from one consistent point across all data shards. Lower values mean fresher snapshots and more CPU load; every rebuild briefly holds back the writes of all data shards.

Default

100

Effect

How often, in milliseconds, the publisher checks whether the shared-memory snapshot is out of date. A check also happens after every MemTable flush. A check compares the position of the key-value write-ahead log and the generation of the domain list with those of the last snapshot. It builds a new snapshot only if they differ, or if a key with an expiry time in the last snapshot has expired since. Otherwise it only confirms the time in the header of the state segment. The build reads all key-value domains from one consistent point across the data shards and serializes them; while it takes that point, the shards hold their writes back for a moment.

The value must be at least 1; 0 refuses the start with invalid config: shm.snapshot_interval_ms (0) must be at least 1. The check runs even while shm.enabled is false.

A new snapshot cannot be published while a client still reads the segment that it would overwrite. The publish is then skipped and the server logs, on every tenth skip in a row, SHM snapshot stale: N consecutive publishes skipped, buffer … still pinned by (client_id, readers) …, and SHM snapshot publishing resumed after N skipped publishes when it works again. snapshot_consecutive_skips in the shm block of GET /store-api/metrics shows the run that is going on. To end a run, see shm.kick_blocking_client_after_secs.

Background

The interval is the staleness a client can see after a write, plus the time of the build: with a write every few milliseconds the snapshot is rebuilt at every interval, and a build reads and serializes all inline key-value data, so its cost grows with the size of that data (shm.data_buffer_size). A shorter interval gives fresher snapshots at the price of more CPU and more moments in which the shards hold their writes. Raise it if the snapshot is large and clients can live with older data.

Referenced on

Write path

`include_auth` backup.schedule.include_auth

Since v0.3.0

Also backs up users and permissions (scopes all and kv only). The backup file then contains API key hashes.

Default

not set

Effect

With true, the backups of this schedule also contain the accounts of the server: for each account its name, role, creation time and the hash of its API key (auth-user lines), and for each account the permissions it holds on domains (auth-perm lines). Without it (the default), an archive holds data only. In a test of v0.5.1 with an on-demand backup of scope all and include_auth set, the archive had one auth-user line for the admin account, with the fields name, api_key_hash, role and created_at.

The setting has an effect only for the scopes all and kv. For every other scope the server leaves the accounts out without a message, and the manifest of the archive says include_auth: false. The key is optional.

The archive then holds SHA-256 hashes of API keys, never the keys themselves. Treat the file as sensitive: it is only as safe as the directory it lies in (backup.dir), the volumes it is copied to and the admins who can download it. When the archive is restored, the accounts come back only if the restore request sets include_auth as well; otherwise the lines are ignored. The accounts that auth.admins.name lists are recreated at every start in any case.

Background

Without accounts, restoring an archive into a new installation leaves you with data and no users, and you have to create the accounts and their permissions again. With them, a restore rebuilds the access rules together with the data. The price is that the archive holds credentials in the form of hashes. Switch it on for the schedule of your full backup if you restore whole installations, and keep the archives as protected as the system store.

Referenced on

Backup and restore

`keep_last` backup.schedule.keep_last

Since v0.3.0

How many of this schedule's newest backups to keep (at least 1).

Default

not set

Effect

How many of the newest backups of this schedule the server keeps. The key is required and must be at least 1; 0 refuses the start with invalid config: backup.schedule.keep_last (0) must be at least 1 (schedule 'a'), and a schedule without it fails to parse with an error that says missing field and names the key. The check runs only while backup.enabled is true.

After every scheduled backup that finished complete, the server lists the archives in backup.dir and deletes the oldest ones of this schedule beyond the number, ordered by creation time. An archive belongs to the schedule if it is complete, was made by this server (not uploaded) and its manifest carries the schedule’s name (backup.schedule.name). A backup that failed triggers no deletion, so a failing schedule never deletes the good archives it should have replaced. Archives made on request, archives of other schedules and uploaded archives are never touched. In a test of v0.5.1, with a schedule mins of * * * * * and keep_last = 2, the directory held the two newest archives of mins after each run, and an archive made on request stayed.

Background

Without retention the directory grows with every run. The number is the length of the history you can go back to: with a nightly schedule and keep_last = 7 you hold the last seven nightly archives. Retention runs only after the new archive is complete, so the directory holds one archive more than the number for a short time; plan the volume for that. A delete by hand through the API works at any time and is not limited by this key.

Referenced on

Backup and restore · Troubleshooting

Removed keys

Keys that a past release accepted and the current one no longer uses. Their entries stay so that old links and search hits still land here.

`scan_batch_size` backup.scan_batch_size

Since v0.3.0Removed in v0.5.1

Number of entries that a backup or restore processed before it paused.
Default: —
Effect: The number of entries that a backup export or a restore processed before it paused for backup.scan_pause_msremoved. A restore also wrote JSON documents in groups of this size. A value of 0 was treated as 1. The default was 500. The key applied only with backup.enabled set to true.
Background: Since v0.5.1 the batch is fixed at 500 entries, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'backup.scan_batch_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Backup and restore

`scan_pause_ms` backup.scan_pause_ms

Since v0.3.0Removed in v0.5.1

Pause in milliseconds after each batch of a backup or restore.
Default: —
Effect: The pause, in milliseconds, that a backup export or a restore made after each batch of backup.scan_batch_sizeremoved entries, so that other requests could run in between. 0 meant no pause. The default was 10. The key applied only with backup.enabled set to true.
Background: Since v0.5.1 the pause is fixed at 10 milliseconds, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'backup.scan_pause_ms' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Backup and restore

`capacity_bytes` block_cache.capacity_bytes

Since v0.1.0Removed in v0.5.1

Maximum size in bytes of the block cache of the key-value engine.
Default: —
Effect: The maximum total size, in bytes, of the block cache of the key-value engine, the cache of SSTable data blocks that sat between the MemTable and the files. Blocks were evicted once the cached blocks together exceeded the value. The default was 67108864 (64 MiB). The server did not check the value.
Background: Since v0.5.1 each engine instance of each data shard has a block cache of its own, and the built-in capacity of 64 MiB is divided by the number of shards (multicore.shards); with 8 shards the start log shows block cache 8192 KiB per engine. The caches count toward the fixed memory that resources.memory_budget is compared with. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'block_cache.capacity_bytes' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`ghost_capacity` block_cache.ghost_capacity

Since v0.1.0Removed in v0.5.1

Number of evicted block identifiers that the block cache of the key-value engine remembered.
Default: —
Effect: The number of identifiers of evicted blocks, without their data, that the block cache of the key-value engine remembered. A block that was requested again while its identifier was still remembered went straight to the main queue. The default was 10000. The server did not check the value.
Background: Since v0.5.1 the number is fixed at 10000, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'block_cache.ghost_capacity' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`small_ratio` block_cache.small_ratio

Since v0.1.0Removed in v0.5.1

Share of the block cache of the key-value engine that the small queue could use.
Default: —
Effect: The share of block_cache.capacity_bytesremoved that the small queue of the block cache of the key-value engine could use, as a number from 0 to 1. The cache works as an S3-FIFO cache: a block that was read for the first time entered the small queue, and a block that was read again moved to the main queue, so one pass over a large range did not push the blocks out that were read often. The default was 0.10. The server did not check the value.
Background: Since v0.5.1 the ratio is fixed at 0.10, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'block_cache.small_ratio' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`registered_buffer_count` io_engine.registered_buffer_count

Since v0.1.0Removed in v0.5.1

Number of buffers that the I/O engine registered with io_uring.
Default: —
Effect: The number of buffers that the I/O engine allocated and registered with the kernel for io_uring at start. It applied only with io_engine.enabled set to true; the default of that key was false. Its default was 128. A successful start logged IoEngine ready: 128 registered buffers x 65536 bytes. with the configured numbers. The engines did not read or write through the buffers, so the key only decided how much memory the registration pinned: the count times io_engine.registered_buffer_sizeremoved, 8 MiB with the defaults. The server did not check the value.
Background: The buffers were groundwork that no read or write path used. Since v0.5.1 the pool is fixed at 128 buffers of 64 KiB, and io_engine.enabled only switches it on. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'io_engine.registered_buffer_count' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`registered_buffer_size` io_engine.registered_buffer_size

Since v0.1.0Removed in v0.5.1

Size in bytes of each buffer that the I/O engine registered with io_uring.
Default: —
Effect: The size, in bytes, of each of the buffers that the I/O engine registered with the kernel for io_uring at start. It applied only with io_engine.enabled set to true; the default of that key was false. Its default was 65536 (64 KiB). The engines did not read or write through the buffers, so the key only decided how much memory the registration pinned: io_engine.registered_buffer_countremoved times this size, 8 MiB with the defaults. The server did not check the value.
Background: The buffers were groundwork that no read or write path used. Since v0.5.1 the pool is fixed at 128 buffers of 64 KiB, and io_engine.enabled only switches it on. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'io_engine.registered_buffer_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`request_channel_capacity` io_engine.request_channel_capacity

Since v0.1.0Removed in v0.5.1

Length of the request queue in front of the storage thread.
Default: —
Effect: The length of the queue in front of the storage thread: requests for the write-ahead log, the value log and the writing of SSTables went through a bounded channel of this size, and the sender waited while the channel was full. A value of 0 was treated as 1. It applied only with io_engine.enabled set to true; the default of that key was false. Its default was 1024.
Background: storage.wal_queue_capacity replaces it. The new key has the same default, 1024, and since v0.5.1 the storage thread always runs, so it always applies. A value set under the old name is not carried over. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'io_engine.request_channel_capacity' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`ring_depth` io_engine.ring_depth

Since v0.1.0Removed in v0.5.1

Depth of the io_uring ring of the storage thread.
Default: —
Effect: The number of entries of the submission queue of the io_uring ring that the storage thread built. It applied only with io_engine.enabled set to true; the default of that key was false. Its default was 256. The server did not check the value.
Background: Since v0.5.1 the depth is fixed at 256. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'io_engine.ring_depth' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`sqpoll_enabled` io_engine.sqpoll_enabled

Since v0.1.0Removed in v0.5.1

Whether the storage thread used an io_uring ring in SQPOLL mode.
Default: —
Effect: Whether the storage thread built its io_uring ring in SQPOLL mode, in which a kernel thread picks up submissions without a system call for each request. The storage thread is the dedicated thread that wrote the write-ahead log and the value log. It ran only with io_engine.enabled set to true, so with the default of false the key had no effect. The default of the key itself was true. When the kernel refused SQPOLL for lack of the capability CAP_SYS_NICE, the thread logged SQPOLL requires CAP_SYS_NICE, falling back to standard mode and used an ordinary ring. The server did not check the value.
Background: Since v0.5.1 the storage thread always runs and always asks for SQPOLL, with the same fallback; its line in the start log says whether SQPOLL is active. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'io_engine.sqpoll_enabled' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Upgrading

`sqpoll_idle_ms` io_engine.sqpoll_idle_ms

Since v0.1.0Removed in v0.5.1

Idle time in milliseconds of the SQPOLL kernel thread of the storage thread.
Default: —
Effect: The time, in milliseconds, that the SQPOLL kernel thread of the storage thread’s ring kept polling for new submissions before it went to sleep. It applied only with io_engine.enabled set to true and io_engine.sqpoll_enabledremoved set to true. The default was 2000. The server did not check the value.
Background: Since v0.5.1 the idle time is fixed at 2000 milliseconds. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'io_engine.sqpoll_idle_ms' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`storage_thread_cpu` io_engine.storage_thread_cpu

Since v0.1.0Removed in v0.5.1

CPU core to which the storage thread was pinned.
Default: —
Effect: The number of the CPU core to which the storage thread pinned itself. The default, -1, left the thread unpinned. When the pinning failed, the thread logged Storage thread CPU pinning to core N failed: … and went on unpinned. It applied only with io_engine.enabled set to true; the default of that key was false. The server did not check the value.
Background: Since v0.5.1 the storage thread is never pinned. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'io_engine.storage_thread_cpu' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`capacity_bytes` json.block_cache.capacity_bytes

Since v0.1.0Removed in v0.5.1

Maximum size in bytes of the block cache of the JSON engine.
Default: —
Effect: The maximum total size, in bytes, of the block cache of the JSON engine, the cache of SSTable data blocks that sat between the MemTable and the files. Blocks were evicted once the cached blocks together exceeded the value. The default was 67108864 (64 MiB). The server did not check the value.
Background: Since v0.5.1 each engine instance of each data shard has a block cache of its own, and the built-in capacity of 64 MiB is divided by the number of shards (multicore.shards); with 8 shards the start log shows block cache 8192 KiB per engine. The caches count toward the fixed memory that resources.memory_budget is compared with. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.block_cache.capacity_bytes' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`ghost_capacity` json.block_cache.ghost_capacity

Since v0.1.0Removed in v0.5.1

Number of evicted block identifiers that the block cache of the JSON engine remembered.
Default: —
Effect: The number of identifiers of evicted blocks, without their data, that the block cache of the JSON engine remembered. A block that was requested again while its identifier was still remembered went straight to the main queue. The default was 10000. The server did not check the value.
Background: Since v0.5.1 the number is fixed at 10000, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.block_cache.ghost_capacity' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`small_ratio` json.block_cache.small_ratio

Since v0.1.0Removed in v0.5.1

Share of the block cache of the JSON engine that the small queue could use.
Default: —
Effect: The share of json.block_cache.capacity_bytesremoved that the small queue of the block cache of the JSON engine could use, as a number from 0 to 1. The cache works as an S3-FIFO cache: a block that was read for the first time entered the small queue, and a block that was read again moved to the main queue, so one pass over a large range did not push the blocks out that were read often. The default was 0.10. The server did not check the value.
Background: Since v0.5.1 the ratio is fixed at 0.10, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.block_cache.small_ratio' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`bulk_batch_size` json.bulk_batch_size

Since v0.1.0Removed in v0.5.1

Number of documents that a JSON bulk import wrote in one batch.
Default: —
Effect: The number of documents that a bulk import into a JSON domain (POST /store-api/json/{domain}/bulk) wrote in one atomic batch. A key that appeared twice in the input started a new batch. A value of 0 was treated as 1. The default was 100.
Background: Since v0.5.1 the batch is fixed at 100 documents, the former default. The size of the request is still limited by json.bulk_body_limit_bytes. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.bulk_batch_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Limits and defaults

`l0_threshold` json.compaction.l0_threshold

Since v0.1.0Removed in v0.5.1

Number of level-0 SSTables at which the JSON engine compacted level 0.
Default: —
Effect: The number of SSTables at level 0 at which the compaction loop of the JSON engine started a compaction of level 0 into level 1. The comparison was “at least”, and every flush of a MemTable added one file at level 0. The default was 4. The server did not check the value.
Background: Since v0.5.1 the JSON engine compacts with the built-in value 4, the former default, and it cannot be changed. The key-value engine keeps its own setting, compaction.l0_threshold. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.compaction.l0_threshold' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`l1_max_size` json.compaction.l1_max_size

Since v0.1.0Removed in v0.5.1

Total size in bytes of level 1 at which the JSON engine compacted it.
Default: —
Effect: The total size, in bytes, of the SSTables at level 1 at which the compaction loop of the JSON engine started a compaction of level 1 into level 2. Deeper levels were limited to this size multiplied by json.compaction.level_size_ratioremoved once for each level below level 1. The default was 104857600 (100 MiB). The server did not check the value.
Background: Since v0.5.1 the JSON engine uses the built-in limit of 100 MiB, the former default, and it cannot be changed. The key-value engine keeps its own setting, compaction.l1_max_size. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.compaction.l1_max_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`level_size_ratio` json.compaction.level_size_ratio

Since v0.1.0Removed in v0.5.1

Factor by which the size limit of the JSON engine grew from one level to the next.
Default: —
Effect: The factor by which the size limit of a level grew from one level to the next: level 1 was limited by json.compaction.l1_max_sizeremoved, and level n from 2 on to that value times this factor to the power n - 1. The default was 10. The server did not check the value.
Background: Since v0.5.1 the JSON engine uses the built-in factor 10, the former default, and it cannot be changed. The key-value engine keeps its own setting, compaction.level_size_ratio. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.compaction.level_size_ratio' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`max_sstable_size` json.compaction.max_sstable_size

Since v0.1.0Removed in v0.5.1

Size at which a compaction of the JSON engine started a new output file.
Default: —
Effect: The size at which a compaction of the JSON engine closed an output file and started the next one. The size was summed from the lengths of the keys and values, a value in the value log counting as its pointer, and the file was closed at the next boundary between two user keys. The files of a flush were not cut by this key. The default was 67108864 (64 MiB). The server did not check the value.
Background: Since v0.5.1 the JSON engine uses the built-in size of 64 MiB, the former default, and it cannot be changed. The key-value engine keeps its own setting, compaction.max_sstable_size. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.compaction.max_sstable_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`check_interval_secs` json.janitor.check_interval_secs

Since v0.1.0Removed in v0.5.1

Seconds between two checks of the value log janitor of the JSON engine.
Default: —
Effect: The pause, in seconds, between two checks of the janitor of the JSON engine, the task that cleans the value log. Each check estimated how much of the log was dead and cleaned it when the estimate reached json.janitor.dead_bytes_thresholdremoved and the log had at least json.janitor.min_vlog_size_bytesremoved bytes. The default was 60. The server did not check the value.
Background: Since v0.5.1 the JSON engine checks every 60 seconds, the former default, and it cannot be changed. The key-value engine keeps its own setting, janitor.check_interval_secs. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.janitor.check_interval_secs' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`dead_bytes_threshold` json.janitor.dead_bytes_threshold

Since v0.1.0Removed in v0.5.1

Share of dead space in the value log at which the JSON engine cleaned it.
Default: —
Effect: The share of the value log that had to be dead, as a number from 0 to 1, before the janitor of the JSON engine cleaned the log. The janitor estimated the share from the size of the log and the bytes that the pointers in the MemTables and SSTables still referenced. The default was 0.30. The server did not check the value.
Background: Since v0.5.1 the JSON engine uses the built-in threshold 0.30, the former default, and it cannot be changed. The key-value engine keeps its own setting, janitor.dead_bytes_threshold. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.janitor.dead_bytes_threshold' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`min_vlog_size_bytes` json.janitor.min_vlog_size_bytes

Since v0.1.0Removed in v0.5.1

Size in bytes that the value log of the JSON engine needed before it was cleaned.
Default: —
Effect: The size, in bytes, that the value log of the JSON engine needed before the janitor could clean it, however much of it was dead. The default was 67108864 (64 MiB). The server did not check the value.
Background: Since v0.5.1 the JSON engine uses the built-in minimum of 64 MiB, the former default, and it cannot be changed. The key-value engine keeps its own setting, janitor.min_vlog_size_bytes. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.janitor.min_vlog_size_bytes' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`compaction_check_interval_ms` json.lsm.compaction_check_interval_ms

Since v0.1.0Removed in v0.5.1

Pause in milliseconds between two turns of the compaction loop of the JSON engine.
Default: —
Effect: The pause, in milliseconds, between two turns of the compaction loop of the JSON engine. In each turn the loop checked the levels of the SSTables against their limits, ran a compaction if a level was over its limit, and then slept for this long. The default was 1000. The server did not check the value.
Background: Since v0.5.1 the pause is fixed at 1000 milliseconds, the former default. The key-value engine keeps its own setting, lsm.compaction_check_interval_ms. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.lsm.compaction_check_interval_ms' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`flush_check_interval_ms` json.lsm.flush_check_interval_ms

Since v0.1.0Removed in v0.5.1

Pause in milliseconds between two turns of the flush loop of the JSON engine.
Default: —
Effect: The pause, in milliseconds, between two turns of the flush loop of the JSON engine. In each turn the loop wrote a frozen MemTable to an SSTable, if there was one, and then slept for this long. The default was 100. The server did not check the value.
Background: Since v0.5.1 the pause is fixed at 100 milliseconds, the former default. The key-value engine keeps its own setting, lsm.flush_check_interval_ms. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.lsm.flush_check_interval_ms' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`memtable_size_threshold` json.lsm.memtable_size_threshold

Since v0.1.0Removed in v0.5.1

Size in bytes at which a MemTable of the JSON engine was flushed.
Default: —
Effect: The size, in bytes, at which the active MemTable of the JSON engine was frozen and queued to be written to an SSTable at level 0. The size counted the encoded keys and the values kept inline, and a value in the value log counted only with its pointer. The default was 4194304 (4 MiB). The server did not check the value.
Background: Since v0.5.1 the JSON engine uses the built-in size of 4 MiB, the former default, and it cannot be changed. The key-value engine keeps its own setting, lsm.memtable_size_threshold. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.lsm.memtable_size_threshold' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`use_mmap` json.lsm.use_mmap

Since v0.1.0Removed in v0.5.1

Whether the JSON engine memory-mapped its SSTables.
Default: —
Effect: Whether the JSON engine opened its SSTables as memory-mapped files (true, the default) or read each file completely into memory (false). The choice applied to every SSTable the engine opened: at start, after a flush, and after a compaction or a cleanup of the value log. The server did not check the value.
Background: Since v0.5.1 the SSTables of every engine are always memory-mapped. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.lsm.use_mmap' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`vlog_inline_threshold` json.lsm.vlog_inline_threshold

Since v0.1.0Removed in v0.5.1

Value size in bytes from which the JSON engine stored values in the value log.
Default: —
Effect: A value of at least this many bytes was appended to the value log of the JSON engine when it was written; the MemTable and the SSTables then kept only a pointer to it. A shorter value stayed inline. The default was 1024. The server did not check the value.
Background: Since v0.5.1 the JSON engine uses the built-in value 1024, the former default, and it cannot be changed. The key-value engine keeps its own setting, lsm.vlog_inline_threshold. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.lsm.vlog_inline_threshold' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`wal_event_channel_capacity` json.lsm.wal_event_channel_capacity

Since v0.1.0Removed in v0.5.1

Capacity of the write-event channel of the JSON engine.
Default: —
Effect: The capacity of the broadcast channel on which the engine of the JSON engine published its write events. Only the watch of the key-value engine read events from such a channel, so for the JSON engine the key sized a channel that nothing listened to. The default was 256. The server did not check the value.
Background: Since v0.5.1 the channel has the built-in capacity of 256, the former default. The key-value engine keeps its own setting, lsm.wal_event_channel_capacity. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.lsm.wal_event_channel_capacity' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`watch_replay_buffer_size` json.lsm.watch_replay_buffer_size

Since v0.4.0Removed in v0.5.1

Size of the watch replay ring of the JSON engine, which the server never used.
Default: —
Effect: The size of the ring that keeps change events for clients that reconnect to a watch stream. The JSON engine has no watch, and the server set the ring size of its engine to 0 whatever this key said, so the value was read from the file and never used. The default was 1024.
Background: Watch streams of data changes exist for the key-value engine only; their replay ring is set by lsm.watch_replay_buffer_size. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.lsm.watch_replay_buffer_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`max_document_key_length` json.max_document_key_length

Since v0.1.0Removed in v0.5.1

Longest document key of the JSON engine.
Default: —
Effect: The longest key, in characters, that a client could give a JSON document. A longer key was refused with 400 and invalid document key: key length N exceeds maximum of M characters, and a bulk import listed it under errors. The limit was the smaller of this value and json.lsm.max_key_length minus 21, the prefix with which the engine stores a document. The default was 256. The server did not check the value.
Background: Since v0.5.1 the cap is fixed at 256. The key length is still limited by json.lsm.max_key_length, which leaves 21 bytes less for the document key: with its default of 256 the longest document key is 235 characters. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.max_document_key_length' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Limits and defaults

`purger_batch_size` json.purger_batch_size

Since v0.1.0Removed in v0.5.1

Number of keys that one purge step removed from a deleted JSON domain.
Default: —
Effect: The number of keys that one purge step of the JSON engine removed from a deleted domain. A deleted domain is unreachable at once, and a background task removes its keys in steps of this size: documents first, then index entries; once nothing is left the task removes the domain itself. A value of 0 was treated as 1. The default was 100.
Background: Since v0.5.1 the step is fixed at 100 keys, the former default; the purge of the key-value engine is set by domains.purger_batch_size. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.purger_batch_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`purger_interval_secs` json.purger_interval_secs

Since v0.1.0Removed in v0.5.1

Seconds between two purge steps of the JSON engine.
Default: —
Effect: The number of seconds between two purge steps of the JSON engine, the background task that removes the keys of deleted domains in steps of json.purger_batch_sizeremoved. The default was 5. The server did not check the value.
Background: Since v0.5.1 the pause is fixed at 5 seconds, the former default; the purge of the key-value engine is set by domains.purger_interval_secs. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.purger_interval_secs' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`reindex_batch_size` json.reindex_batch_size

Since v0.1.0Removed in v0.5.1

Number of documents that an index rebuild processed in one step.
Default: —
Effect: The number of documents that a rebuild of the indexes of a JSON domain (POST /store-api/json/{domain}/reindex) processed in one step. A value of 0 was treated as 1. The default was 500.
Background: Since v0.5.1 the batch is fixed at 500 documents, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.reindex_batch_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Limits and defaults

`reindex_pause_ms` json.reindex_pause_ms

Since v0.1.0Removed in v0.5.1

Pause in milliseconds between two steps of an index rebuild.
Default: —
Effect: The pause, in milliseconds, that an index rebuild of a JSON domain made after each step of json.reindex_batch_sizeremoved documents, so that other requests could run in between. 0 meant no pause. The default was 10.
Background: Since v0.5.1 the pause is fixed at 10 milliseconds, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'json.reindex_pause_ms' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`domains` log.modules.domains

Since v0.1.0Removed in v0.5.1

Log level of the domain registry module of the key-value engine.
Default: —
Effect: The log level of the module luradb::engines::lsm::domain, the domain registry of the key-value engine, in place of log.level. The values were verbose, info and prod, the same as for the global level; they set the filter to debug, info and warn. Without the key the module followed the global level. Any other value refused the start with a parse error of the configuration file.
Background: Since v0.5.1 the module has no setting of its own. Its name begins with luradb::engines, so log.modules.engine sets its level together with that of the other engine modules. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'log.modules.domains' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`use_mmap` lsm.use_mmap

Since v0.1.0Removed in v0.5.1

Whether the key-value engine memory-mapped its SSTables.
Default: —
Effect: Whether the key-value engine opened its SSTables as memory-mapped files (true, the default) or read each file completely into memory (false). The choice applied to every SSTable the engine opened: at start, after a flush, and after a compaction or a cleanup of the value log. The server did not check the value.
Background: Since v0.5.1 the SSTables of every engine are always memory-mapped. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'lsm.use_mmap' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Upgrading

`ticker_interval_ms` metrics.ticker_interval_ms

Since v0.1.0Removed in v0.5.1

Interval in milliseconds at which the metrics windows advance.
Default: —
Effect: How often, in milliseconds, the background ticker of the metrics store closed the current snapshot of every window and opened the next one. The default was 1000, one snapshot per second. A window held metrics.window_secsremoved snapshots, so another interval changed the time that the window covered while the answer still reported window_secs: with 500 the 60 snapshots covered 30 seconds. The server did not check the value.
Background: Since v0.5.1 the ticker runs once per second. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'metrics.ticker_interval_ms' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`window_secs` metrics.window_secs

Since v0.1.0Removed in v0.5.1

Width in seconds of the rolling window of the metrics endpoint.
Default: —
Effect: The width of the rolling window, in seconds, over which GET /store-api/metrics counted operations and computed latency percentiles, for each domain and each engine. The window kept this many snapshots, one for each tick of the metrics ticker (metrics.ticker_interval_msremoved), and added them up; the answer repeats the number as window_secs. The default was 60. The server did not check the value.
Background: Since v0.5.1 the window is always 60 seconds, and the answers report window_secs as 60. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'metrics.window_secs' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`engine_queue_capacity` multicore.engine_queue_capacity

Removed in v0.5.1

Length of the queue to the single engine thread, in builds before v0.5.0-rc.1.
Default: —
Effect: The length of the queue through which the frontend threads handed requests to the engine thread, when the storage engines still ran on a single thread. A full queue held further requests back. The default was 1024, and the value had to be at least 1: invalid config: multicore.engine_queue_capacity (0) must be at least 1 otherwise. The key existed only in development builds between v0.4.0 and v0.5.0-rc.1; no tagged release read it.
Background: multicore.shard_queue_capacity replaces it. With data shards (multicore.shards) every shard has a queue of its own: the key sets how many requests a shard takes at once, running or waiting, and a request that finds the queue full is answered with 503 and Retry-After: 1 instead of waiting. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'multicore.engine_queue_capacity' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`capacity_bytes` rel.block_cache.capacity_bytes

Since v0.1.0Removed in v0.5.1

Maximum size in bytes of the block cache of the relational engine.
Default: —
Effect: The maximum total size, in bytes, of the block cache of the relational engine, the cache of SSTable data blocks that sat between the MemTable and the files. Blocks were evicted once the cached blocks together exceeded the value. The default was 67108864 (64 MiB). The server did not check the value.
Background: Since v0.5.1 each engine instance of each data shard has a block cache of its own, and the built-in capacity of 64 MiB is divided by the number of shards (multicore.shards); with 8 shards the start log shows block cache 8192 KiB per engine. The caches count toward the fixed memory that resources.memory_budget is compared with. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.block_cache.capacity_bytes' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`ghost_capacity` rel.block_cache.ghost_capacity

Since v0.1.0Removed in v0.5.1

Number of evicted block identifiers that the block cache of the relational engine remembered.
Default: —
Effect: The number of identifiers of evicted blocks, without their data, that the block cache of the relational engine remembered. A block that was requested again while its identifier was still remembered went straight to the main queue. The default was 10000. The server did not check the value.
Background: Since v0.5.1 the number is fixed at 10000, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.block_cache.ghost_capacity' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`small_ratio` rel.block_cache.small_ratio

Since v0.1.0Removed in v0.5.1

Share of the block cache of the relational engine that the small queue could use.
Default: —
Effect: The share of rel.block_cache.capacity_bytesremoved that the small queue of the block cache of the relational engine could use, as a number from 0 to 1. The cache works as an S3-FIFO cache: a block that was read for the first time entered the small queue, and a block that was read again moved to the main queue, so one pass over a large range did not push the blocks out that were read often. The default was 0.10. The server did not check the value.
Background: Since v0.5.1 the ratio is fixed at 0.10, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.block_cache.small_ratio' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`l0_threshold` rel.compaction.l0_threshold

Since v0.1.0Removed in v0.5.1

Number of level-0 SSTables at which the relational engine compacted level 0.
Default: —
Effect: The number of SSTables at level 0 at which the compaction loop of the relational engine started a compaction of level 0 into level 1. The comparison was “at least”, and every flush of a MemTable added one file at level 0. The default was 4. The server did not check the value.
Background: Since v0.5.1 the relational engine compacts with the built-in value 4, the former default, and it cannot be changed. The key-value engine keeps its own setting, compaction.l0_threshold. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.compaction.l0_threshold' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`l1_max_size` rel.compaction.l1_max_size

Since v0.1.0Removed in v0.5.1

Total size in bytes of level 1 at which the relational engine compacted it.
Default: —
Effect: The total size, in bytes, of the SSTables at level 1 at which the compaction loop of the relational engine started a compaction of level 1 into level 2. Deeper levels were limited to this size multiplied by rel.compaction.level_size_ratioremoved once for each level below level 1. The default was 104857600 (100 MiB). The server did not check the value.
Background: Since v0.5.1 the relational engine uses the built-in limit of 100 MiB, the former default, and it cannot be changed. The key-value engine keeps its own setting, compaction.l1_max_size. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.compaction.l1_max_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`level_size_ratio` rel.compaction.level_size_ratio

Since v0.1.0Removed in v0.5.1

Factor by which the size limit of the relational engine grew from one level to the next.
Default: —
Effect: The factor by which the size limit of a level grew from one level to the next: level 1 was limited by rel.compaction.l1_max_sizeremoved, and level n from 2 on to that value times this factor to the power n - 1. The default was 10. The server did not check the value.
Background: Since v0.5.1 the relational engine uses the built-in factor 10, the former default, and it cannot be changed. The key-value engine keeps its own setting, compaction.level_size_ratio. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.compaction.level_size_ratio' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`max_sstable_size` rel.compaction.max_sstable_size

Since v0.1.0Removed in v0.5.1

Size at which a compaction of the relational engine started a new output file.
Default: —
Effect: The size at which a compaction of the relational engine closed an output file and started the next one. The size was summed from the lengths of the keys and values, a value in the value log counting as its pointer, and the file was closed at the next boundary between two user keys. The files of a flush were not cut by this key. The default was 67108864 (64 MiB). The server did not check the value.
Background: Since v0.5.1 the relational engine uses the built-in size of 64 MiB, the former default, and it cannot be changed. The key-value engine keeps its own setting, compaction.max_sstable_size. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.compaction.max_sstable_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`cross_engine_sweep_batch_size` rel.cross_engine_sweep_batch_size

Since v0.1.0Removed in v0.5.1

Number of cells that the sweeper for links nulled per run.
Default: —
Effect: The largest number of cells that the sweeper of rel.cross_engine_sweep_interval_secsremoved set to NULL in one run for one link column of one domain; a larger backlog took several runs. A value of 0 was treated as 1. The default was 100.
Background: Since v0.5.1 the batch is fixed at 100 cells, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.cross_engine_sweep_batch_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Limits and defaults

`cross_engine_sweep_interval_secs` rel.cross_engine_sweep_interval_secs

Since v0.1.0Removed in v0.5.1

Seconds between two runs of the sweeper for links to deleted domains.
Default: —
Effect: The pause, in seconds, between two runs of the sweeper that cleaned up links from the relational engine to the other engines. When the key-value or JSON domain that a KVREF or JSONREF column points to is deleted, reads show the cell as NULL; the sweeper then set such cells to NULL in the stored rows. It ran only when at least one engine that rows could link to was running. A value of 0 was treated as 1. The default was 10.
Background: Since v0.5.1 the sweeper runs every 10 seconds, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.cross_engine_sweep_interval_secs' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Limits and defaults

`default_limit` rel.default_limit

Since v0.1.0Removed in v0.5.1

Number of rows returned when a query has no LIMIT.
Default: —
Effect: The number of rows that a SELECT without LIMIT, and the row endpoint of a table without a limit parameter, returned at most; rel.max_limit capped it. When more rows existed, the answer said so with "limit_applied": true. The default was 1000. The server did not check the value.
Background: Since v0.5.1 a query without a limit returns at most 1,000 rows, the former default, or rel.max_limit if that is smaller. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.default_limit' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Limits and defaults

`check_interval_secs` rel.janitor.check_interval_secs

Since v0.1.0Removed in v0.5.1

Seconds between two checks of the value log janitor of the relational engine.
Default: —
Effect: The pause, in seconds, between two checks of the janitor of the relational engine, the task that cleans the value log. Each check estimated how much of the log was dead and cleaned it when the estimate reached rel.janitor.dead_bytes_thresholdremoved and the log had at least rel.janitor.min_vlog_size_bytesremoved bytes. The default was 60. The server did not check the value.
Background: Since v0.5.1 the relational engine checks every 60 seconds, the former default, and it cannot be changed. The key-value engine keeps its own setting, janitor.check_interval_secs. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.janitor.check_interval_secs' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`dead_bytes_threshold` rel.janitor.dead_bytes_threshold

Since v0.1.0Removed in v0.5.1

Share of dead space in the value log at which the relational engine cleaned it.
Default: —
Effect: The share of the value log that had to be dead, as a number from 0 to 1, before the janitor of the relational engine cleaned the log. The janitor estimated the share from the size of the log and the bytes that the pointers in the MemTables and SSTables still referenced. The default was 0.30. The server did not check the value.
Background: Since v0.5.1 the relational engine uses the built-in threshold 0.30, the former default, and it cannot be changed. The key-value engine keeps its own setting, janitor.dead_bytes_threshold. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.janitor.dead_bytes_threshold' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`min_vlog_size_bytes` rel.janitor.min_vlog_size_bytes

Since v0.1.0Removed in v0.5.1

Size in bytes that the value log of the relational engine needed before it was cleaned.
Default: —
Effect: The size, in bytes, that the value log of the relational engine needed before the janitor could clean it, however much of it was dead. The default was 67108864 (64 MiB). The server did not check the value.
Background: Since v0.5.1 the relational engine uses the built-in minimum of 64 MiB, the former default, and it cannot be changed. The key-value engine keeps its own setting, janitor.min_vlog_size_bytes. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.janitor.min_vlog_size_bytes' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`compaction_check_interval_ms` rel.lsm.compaction_check_interval_ms

Since v0.1.0Removed in v0.5.1

Pause in milliseconds between two turns of the compaction loop of the relational engine.
Default: —
Effect: The pause, in milliseconds, between two turns of the compaction loop of the relational engine. In each turn the loop checked the levels of the SSTables against their limits, ran a compaction if a level was over its limit, and then slept for this long. The default was 1000. The server did not check the value.
Background: Since v0.5.1 the pause is fixed at 1000 milliseconds, the former default. The key-value engine keeps its own setting, lsm.compaction_check_interval_ms. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.lsm.compaction_check_interval_ms' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`flush_check_interval_ms` rel.lsm.flush_check_interval_ms

Since v0.1.0Removed in v0.5.1

Pause in milliseconds between two turns of the flush loop of the relational engine.
Default: —
Effect: The pause, in milliseconds, between two turns of the flush loop of the relational engine. In each turn the loop wrote a frozen MemTable to an SSTable, if there was one, and then slept for this long. The default was 100. The server did not check the value.
Background: Since v0.5.1 the pause is fixed at 100 milliseconds, the former default. The key-value engine keeps its own setting, lsm.flush_check_interval_ms. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.lsm.flush_check_interval_ms' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`max_value_size` rel.lsm.max_value_size

Since v0.1.0Removed in v0.5.1

Largest value in bytes that the storage of the relational engine accepted.
Default: —
Effect: The largest value, in bytes, that the storage of the relational engine accepted. A write of a value above it, such as a row, was refused by the engine with Value length N exceeds maximum of M bytes; rel.max_row_size limited the encoded row separately. The default was 524288 (512 KiB). The value must not exceed 100663296 bytes (96 MiB), the largest field that the recovery of the write-ahead log reads; the start was refused with invalid config: rel.lsm.max_value_size (…) exceeds the WAL recovery field cap (100663296 bytes) — writes this large could never be recovered otherwise.
Background: rel.max_row_size replaces it. Since v0.5.1 the storage limit of the relational engine follows that key: it is the larger of 512 KiB and rel.max_row_size, so one key sets the size of rows. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.lsm.max_value_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`memtable_size_threshold` rel.lsm.memtable_size_threshold

Since v0.1.0Removed in v0.5.1

Size in bytes at which a MemTable of the relational engine was flushed.
Default: —
Effect: The size, in bytes, at which the active MemTable of the relational engine was frozen and queued to be written to an SSTable at level 0. The size counted the encoded keys and the values kept inline, and a value in the value log counted only with its pointer. The default was 4194304 (4 MiB). The server did not check the value.
Background: Since v0.5.1 the relational engine uses the built-in size of 4 MiB, the former default, and it cannot be changed. The key-value engine keeps its own setting, lsm.memtable_size_threshold. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.lsm.memtable_size_threshold' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`use_mmap` rel.lsm.use_mmap

Since v0.1.0Removed in v0.5.1

Whether the relational engine memory-mapped its SSTables.
Default: —
Effect: Whether the relational engine opened its SSTables as memory-mapped files (true, the default) or read each file completely into memory (false). The choice applied to every SSTable the engine opened: at start, after a flush, and after a compaction or a cleanup of the value log. The server did not check the value.
Background: Since v0.5.1 the SSTables of every engine are always memory-mapped. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.lsm.use_mmap' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`vlog_inline_threshold` rel.lsm.vlog_inline_threshold

Since v0.1.0Removed in v0.5.1

Value size in bytes from which the relational engine stored values in the value log.
Default: —
Effect: A value of at least this many bytes was appended to the value log of the relational engine when it was written; the MemTable and the SSTables then kept only a pointer to it. A shorter value stayed inline. The default was 1024. The server did not check the value.
Background: Since v0.5.1 the relational engine uses the built-in value 1024, the former default, and it cannot be changed. The key-value engine keeps its own setting, lsm.vlog_inline_threshold. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.lsm.vlog_inline_threshold' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`wal_event_channel_capacity` rel.lsm.wal_event_channel_capacity

Since v0.1.0Removed in v0.5.1

Capacity of the write-event channel of the relational engine.
Default: —
Effect: The capacity of the broadcast channel on which the engine of the relational engine published its write events. Only the watch of the key-value engine read events from such a channel, so for the relational engine the key sized a channel that nothing listened to. The default was 256. The server did not check the value.
Background: Since v0.5.1 the channel has the built-in capacity of 256, the former default. The key-value engine keeps its own setting, lsm.wal_event_channel_capacity. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.lsm.wal_event_channel_capacity' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`watch_replay_buffer_size` rel.lsm.watch_replay_buffer_size

Since v0.4.0Removed in v0.5.1

Size of the watch replay ring of the relational engine, which the server never used.
Default: —
Effect: The size of the ring that keeps change events for clients that reconnect to a watch stream. The relational engine has no watch, and the server set the ring size of its engine to 0 whatever this key said, so the value was read from the file and never used. The default was 1024.
Background: Watch streams of data changes exist for the key-value engine only; their replay ring is set by lsm.watch_replay_buffer_size. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.lsm.watch_replay_buffer_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`max_columns` rel.max_columns

Since v0.1.0Removed in v0.5.1

Largest number of columns of a table.
Default: —
Effect: The largest number of columns a table could have. CREATE TABLE with more columns, ALTER TABLE … ADD COLUMN on a table that already had this many, and the creation of a table from a file with more columns were refused with limit exceeded: max_columns (max N); the REST API answered 400. The default was 128. The server did not check the value.
Background: Since v0.5.1 the limit is fixed at 128, the former default. rel.max_tables_per_domain still limits the tables of a domain. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.max_columns' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Limits and defaults

`max_indexes_per_table` rel.max_indexes_per_table

Since v0.1.0Removed in v0.5.1

Largest number of indexes of a table.
Default: —
Effect: The largest number of indexes a table could have. CREATE TABLE with more UNIQUE columns than this (the primary key does not count), and CREATE INDEX on a table that already had this many indexes, were refused with limit exceeded: max_indexes_per_table (max N); the REST API answered 400. The default was 16. The server did not check the value.
Background: Since v0.5.1 the limit is fixed at 16, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.max_indexes_per_table' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Limits and defaults

`max_join_depth` rel.max_join_depth

Since v0.1.0Removed in v0.5.1

Largest number of join stages of a statement.
Default: —
Effect: The largest number of join stages that one statement could use. Each LEFT JOIN counted as one, and so did each expanded link column; a statement over the limit was refused with 400 and join depth N exceeds the maximum of M. A view was checked when it was created. The default was 8. The server did not check the value.
Background: Since v0.5.1 the limit is fixed at 8, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.max_join_depth' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Limits and defaults

`max_response_bytes` rel.max_response_bytes

Since v0.1.0Removed in v0.5.1

Largest serialized response of a SQL statement or row listing in bytes.
Default: —
Effect: The largest serialized response, in bytes, of a POST /store-api/rel/{domain}/sql statement or of the row endpoint of a table, expanded links included. A larger response was refused with 413 and Payload Too Large: response exceeds max_response_bytes; reduce LIMIT. The default was 33554432 (32 MiB). The server did not check the value.
Background: Since v0.5.1 the limit is fixed at 32 MiB, the former default. Keep the result below it with LIMIT; rel.max_limit caps the number of rows. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.max_response_bytes' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Limits and defaults

`max_statement_len` rel.max_statement_len

Since v0.1.0Removed in v0.5.1

Longest SQL statement in bytes.
Default: —
Effect: The longest SQL statement, in bytes, that the relational engine accepted. A longer statement was refused before it was parsed, with 400 and statement length N exceeds maximum of M bytes. The default was 65536 (64 KiB). The server did not check the value.
Background: Since v0.5.1 the limit is fixed at 64 KiB, the former default. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.max_statement_len' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Limits and defaults

`max_text_len` rel.max_text_len

Since v0.1.0Removed in v0.5.1

Longest TEXT value in bytes.
Default: —
Effect: The longest value, in bytes, of a TEXT column, including the link columns KVREF and JSONREF, that an INSERT or UPDATE could write. A longer value was refused with 400 and text length N exceeds maximum of M bytes. The default was 65536 (64 KiB). The server did not check the value.
Background: Since v0.5.1 the limit is fixed at 64 KiB, the former default. rel.max_row_size still limits the whole row. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.max_text_len' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Limits and defaults

`purger_batch_size` rel.purger_batch_size

Since v0.1.0Removed in v0.5.1

Number of keys that one purge step removed from a deleted relational domain.
Default: —
Effect: The number of keys that one purge step of the relational engine removed from a deleted domain. A deleted domain is unreachable at once, and a background task removes its keys in steps of this size: rows, index entries and AUTOINCREMENT counters; once nothing is left the task removes the domain itself. The same task also reaped the data of dropped tables and indexes, with the same step size. A value of 0 was treated as 1. The default was 100.
Background: Since v0.5.1 the step is fixed at 100 keys, the former default; the purge of the key-value engine is set by domains.purger_batch_size. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.purger_batch_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`purger_interval_secs` rel.purger_interval_secs

Since v0.1.0Removed in v0.5.1

Seconds between two purge steps of the relational engine.
Default: —
Effect: The number of seconds between two purge steps of the relational engine, the background task that removes the keys of deleted domains in steps of rel.purger_batch_sizeremoved. The default was 5. The server did not check the value.
Background: Since v0.5.1 the pause is fixed at 5 seconds, the former default; the purge of the key-value engine is set by domains.purger_interval_secs. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'rel.purger_interval_secs' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`unix_socket_mode` server.unix_socket_mode

Since v0.1.0Removed in v0.5.1

File mode of the Unix socket.
Default: —
Effect: The file mode that the server gave the socket named by server.unix_socket_path once it had bound it. The value was a whole number, written in decimal in TOML: 432 is 0o660. Without the key the mode was 0o660, which lets the owner and the group of the socket read and write it. The key had no effect while no socket path was set. The server did not check the value.
Background: Who may connect to the socket was decided by this mode together with the owner and the group of the socket and the permissions of its directory. Since v0.5.1 the mode is always 0o660; give clients access through the owner or the group of the socket. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'server.unix_socket_mode' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: Limits and defaults

`command_buffer_size` shm.command_buffer_size

Since v0.1.0Removed in v0.5.1

Size in bytes of the command and response rings of each shared-memory client.
Default: —
Effect: The size, in bytes, of the ring buffers that each client of the shared-memory interface received when it registered, for commands to the server and for responses. It applied only with shm.enabled set to true. The default was 4194304 (4 MiB). The value had to be a power of two and at least 4096; otherwise the start was refused with shm.command_buffer_size must be a power of two, got N or shm.command_buffer_size must be at least 4096 bytes, got N.
Background: Since v0.5.1 the rings have the fixed size of 4 MiB. The size of the snapshot buffers is still set by shm.data_buffer_size. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'shm.command_buffer_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`segment_mode` shm.segment_mode

Since v0.1.0Removed in v0.5.1

File mode of the shared-memory segments.
Default: —
Effect: The file mode that the server gave the shared-memory segments it created, the state and data segments and the rings of each client. The value was a whole number, written in decimal in TOML: 432 is 0o660. It applied only with shm.enabled set to true. The default was 0o660 (432). The server did not check the value.
Background: Since v0.5.1 the mode is always 0o660, so the segments cannot be opened up to other users through the configuration. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'shm.segment_mode' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

`state_size` shm.state_size

Since v0.1.0Removed in v0.5.1

Size in bytes of the state segment of the shared-memory interface.
Default: —
Effect: The size, in bytes, of the shared-memory segment state, which holds the state header of the shared-memory interface. It applied only with shm.enabled set to true. The default was 4096. The value had to be at least the size of the state header; otherwise the start was refused with shm.state_size must be at least N bytes, got M.
Background: Since v0.5.1 the segment has the fixed size of 4096 bytes. The v0.5.1 server accepts a luradb.toml that still sets the key: it starts normally, ignores the value and logs unknown config key 'shm.state_size' is ignored as a warning, once, at startup. Remove the line to silence the warning.
Referenced on: —

Configuration reference

[server]

swagger_enabled [server]server.swagger_enabled

swagger_url [server]server.swagger_url

bind_address [server]server.bind_address

port [server]server.port

http_enabled [server]server.http_enabled

hello_enabled [server]server.hello_enabled

hello_message [server]server.hello_message

unix_socket_path [server]server.unix_socket_path

tls_enabled [server]server.tls_enabled

tls_port [server]server.tls_port

tls_cert_path [server]server.tls_cert_path

tls_key_path [server]server.tls_key_path

[auth]

enabled [auth]auth.enabled

trusted_uids [auth]auth.trusted_uids

[[auth.admins]]

name [auth.admins]auth.admins.name

api_key [auth.admins]auth.admins.api_key

[storage]

db_path [storage]storage.db_path

wal_path [storage]storage.wal_path

vlog_path [storage]storage.vlog_path

sstable_dir [storage]storage.sstable_dir

system_dir [storage]storage.system_dir

wal_queue_capacity [storage]storage.wal_queue_capacity

wal_max_size [storage]storage.wal_max_size

[resources]

disk_free_warn [resources]resources.disk_free_warn

disk_free_block [resources]resources.disk_free_block

disk_free_resume [resources]resources.disk_free_resume

memory_budget [resources]resources.memory_budget

[io_engine]

enabled [io_engine]io_engine.enabled

[multicore]

cpu_offload_threads [multicore]multicore.cpu_offload_threads

frontend_workers [multicore]multicore.frontend_workers

shards [multicore]multicore.shards

shard_queue_capacity [multicore]multicore.shard_queue_capacity

reader_threads [multicore]multicore.reader_threads

reader_queue_capacity [multicore]multicore.reader_queue_capacity

[buffer_pool]

pool_size [buffer_pool]buffer_pool.pool_size

[lsm]

vlog_inline_threshold [lsm]lsm.vlog_inline_threshold

memtable_size_threshold [lsm]lsm.memtable_size_threshold

max_key_length [lsm]lsm.max_key_length

max_value_size [lsm]lsm.max_value_size

flush_check_interval_ms [lsm]lsm.flush_check_interval_ms

compaction_check_interval_ms [lsm]lsm.compaction_check_interval_ms

wal_event_channel_capacity [lsm]lsm.wal_event_channel_capacity

watch_replay_buffer_size [lsm]lsm.watch_replay_buffer_size

[compaction]

l0_threshold [compaction]compaction.l0_threshold

l1_max_size [compaction]compaction.l1_max_size

level_size_ratio [compaction]compaction.level_size_ratio

max_sstable_size [compaction]compaction.max_sstable_size

[janitor]

check_interval_secs [janitor]janitor.check_interval_secs

dead_bytes_threshold [janitor]janitor.dead_bytes_threshold

min_vlog_size_bytes [janitor]janitor.min_vlog_size_bytes

[ttl_sweeper]

enabled [ttl_sweeper]ttl_sweeper.enabled

interval_secs [ttl_sweeper]ttl_sweeper.interval_secs

batch_size [ttl_sweeper]ttl_sweeper.batch_size

[domains]

max_name_length [domains]domains.max_name_length

max_user_key_length [domains]domains.max_user_key_length

default_domain [domains]domains.default_domain

purger_batch_size [domains]domains.purger_batch_size

purger_interval_secs [domains]domains.purger_interval_secs

max_bulk_delete_keys [domains]domains.max_bulk_delete_keys

[rate_limit]

default_read_iops [rate_limit]rate_limit.default_read_iops

default_write_iops [rate_limit]rate_limit.default_write_iops

default_max_storage_bytes [rate_limit]rate_limit.default_max_storage_bytes

[json]

enabled [json]json.enabled

wal_path [json]json.wal_path

`[server]`

`swagger_enabled` server.swagger_enabled

`swagger_url` server.swagger_url

`bind_address` server.bind_address

`port` server.port

`http_enabled` server.http_enabled

`hello_enabled` server.hello_enabled

`hello_message` server.hello_message

`unix_socket_path` server.unix_socket_path

`tls_enabled` server.tls_enabled

`tls_port` server.tls_port

`tls_cert_path` server.tls_cert_path

`tls_key_path` server.tls_key_path

`[auth]`

`enabled` auth.enabled

`trusted_uids` auth.trusted_uids

`[[auth.admins]]`

`name` auth.admins.name

`api_key` auth.admins.api_key

`[storage]`

`db_path` storage.db_path

`wal_path` storage.wal_path

`vlog_path` storage.vlog_path

`sstable_dir` storage.sstable_dir

`system_dir` storage.system_dir

`wal_queue_capacity` storage.wal_queue_capacity

`wal_max_size` storage.wal_max_size

`[resources]`

`disk_free_warn` resources.disk_free_warn

`disk_free_block` resources.disk_free_block

`disk_free_resume` resources.disk_free_resume

`memory_budget` resources.memory_budget

`[io_engine]`

`enabled` io_engine.enabled

`[multicore]`

`cpu_offload_threads` multicore.cpu_offload_threads

`frontend_workers` multicore.frontend_workers

`shards` multicore.shards

`shard_queue_capacity` multicore.shard_queue_capacity

`reader_threads` multicore.reader_threads

`reader_queue_capacity` multicore.reader_queue_capacity

`[buffer_pool]`

`pool_size` buffer_pool.pool_size

`[lsm]`

`vlog_inline_threshold` lsm.vlog_inline_threshold

`memtable_size_threshold` lsm.memtable_size_threshold

`max_key_length` lsm.max_key_length

`max_value_size` lsm.max_value_size

`flush_check_interval_ms` lsm.flush_check_interval_ms

`compaction_check_interval_ms` lsm.compaction_check_interval_ms

`wal_event_channel_capacity` lsm.wal_event_channel_capacity

`watch_replay_buffer_size` lsm.watch_replay_buffer_size

`[compaction]`

`l0_threshold` compaction.l0_threshold

`l1_max_size` compaction.l1_max_size

`level_size_ratio` compaction.level_size_ratio

`max_sstable_size` compaction.max_sstable_size

`[janitor]`

`check_interval_secs` janitor.check_interval_secs

`dead_bytes_threshold` janitor.dead_bytes_threshold

`min_vlog_size_bytes` janitor.min_vlog_size_bytes

`[ttl_sweeper]`

`enabled` ttl_sweeper.enabled

`interval_secs` ttl_sweeper.interval_secs

`batch_size` ttl_sweeper.batch_size

`[domains]`

`max_name_length` domains.max_name_length

`max_user_key_length` domains.max_user_key_length

`default_domain` domains.default_domain

`purger_batch_size` domains.purger_batch_size

`purger_interval_secs` domains.purger_interval_secs

`max_bulk_delete_keys` domains.max_bulk_delete_keys

`[rate_limit]`

`default_read_iops` rate_limit.default_read_iops

`default_write_iops` rate_limit.default_write_iops

`default_max_storage_bytes` rate_limit.default_max_storage_bytes

`[json]`

`enabled` json.enabled

`wal_path` json.wal_path

`vlog_path` json.vlog_path