TypeDB Configuration

You can configure a TypeDB server via two means: a YAML config file or command line options. Command line options override values defined in the config file.

For a full list of configurable properties run:

typedb server --help

This page lists & explains the available options.

General CLI arguments

General, non-configuration arguments available on the CLI.

General CLI arguments

--config <path-to-file>

Specify a custom configuration file

--help

-h

Show help message.

--version

-V

Print version information and exit.

Configuration file

By default, TypeDB looks for a config.yml file in the same folder as the TypeDB server executable (i.e., /server/config.yml). This path can be overridden using the CLI argument: --config <path-to-your-config>.

Command line overrides

When using the command line to override a specific option, all CLI arguments must:

  • start with the double dash prefix --,

  • be separated from their value (if any) either by an equals sign (--arg=val) or a whitespace (--arg val).

e.g., --server.listen-address=0.0.0.0:1730

Configuration options

The options below apply to every TypeDB server. TypeDB Enterprise servers have additional clustering options.

Server

The server section of the configuration contains network and encryption options. For example, a server can be booted up to listen on 0.0.0.0:1730 by using this command:

typedb server --server.listen-address=0.0.0.0:1730

Listen vs. advertise addresses

Each public network endpoint has two addresses:

  • The listen address is what the server binds to locally — the interface and port where it accepts connections.

  • The advertise address is what the server reports back to clients. Clients use the advertise address to connect if it is presented.

When the server is reached directly, both can be the same. When the server sits behind a NAT, reverse proxy, or load balancer, the listen address is the local bind (often 0.0.0.0:<port>) and the advertise address is the externally-reachable host:port that clients should dial.

If advertise-address is omitted, the server does not report back any address to gRPC/HTTP connections. Then, the clients must not depend on the server’s information, using the initial connection address for further communication.

In a cluster, advertise addresses must be set: clients connect to every replica, and to a new primary after a failover, at its advertise address, so a load balancer or proxy only serves their first contact. Clients that cannot reach the advertise addresses use address translation instead; see How clients reach the replicas.

Server

server.listen-address

Server gRPC listen host and port — the address the server binds to. Default value: 0.0.0.0:1729.
Alias (deprecated): server.address. Specifying both server.listen-address and server.address is rejected.

server.advertise-address

Server gRPC advertise host and port — the address shared with clients. Required when the listen and advertise addresses differ (e.g., behind a proxy or NAT).

server.http.enabled

Enable/disable HTTP endpoint. Default value: true.

server.http.listen-address

HTTP listen host and port — the address the server binds to. Cannot be the same as server.listen-address. Default value: 0.0.0.0:8000.
Alias (deprecated): server.http.address. Specifying both server.http.listen-address and server.http.address is rejected.

server.http.advertise-address

HTTP advertise URL shared with clients (include the scheme, e.g. http://127.0.0.1:8000 or https://typedb.example.com). Required when the listen and advertise addresses differ. Default value: derived from server.http.listen-address.

server.authentication.token-expiration-seconds

The amount of seconds generated authentication tokens will remain valid, specified in seconds. Default value: 14400 (4 hours).

Admin endpoint

TypeDB exposes a separate admin gRPC endpoint over a local IPC channel — a Unix domain socket on Linux and macOS, a Named Pipe on Windows — used by the bundled typedb admin CLI tool to inspect and manage a running server (see TypeDB Admin Tool).

Server admin

server.admin.enabled

Enable/disable the local admin endpoint. Default value: false.

server.admin.socket-path

Filesystem path of the admin Unix domain socket (Linux/macOS) or the Named Pipe name (Windows). Default value: <data-directory>/admin.sock on Linux/macOS, \\.\pipe\typedb-admin on Windows.
On Linux/macOS the path must be short enough to fit sun_path (typically ≤ 108 bytes).

Encryption

Configure the TLS certificate & private-key to be used for inflight encryption.

Server encryption

server.encryption.enabled

Enable in-flight encryption. Do not specify this argument to leave it disabled.

server.encryption.certificate

Encryption certificate in PEM format. Must be supplied if encryption is enabled.

server.encryption.certificate-key

Encryption certificate key. Must be supplied if encryption is enabled.

server.encryption.ca-certificate

Encryption CA in PEM format. (Optional)

Storage

The storage section of the configuration contains the storage layer options.

For production use, it is recommended that the storage.data-directory is set to a path outside the $TYPEDB_HOME (directory with TypeDB server files).

This helps to make the process of upgrading TypeDB easier.

Storage

storage.data-directory

Path to the user data directory. Defaults to within the server distribution under server/data.

storage.rocksdb.cache-size

Size of the shared RocksDB block cache, the in-memory cache of data blocks read from disk. This is a single pool shared by all databases on the server. Default value: 1gb (1 GiB).
This is a soft limit: it may be exceeded by index and filter blocks that RocksDB pins in memory.

storage.rocksdb.write-buffers-limit

Total memory budget for the RocksDB write-buffer manager — the in-memory write buffers (memtables) that hold writes before they are organized on disk. This is a single pool shared by all databases on the server. Default value: 512mb (512 MiB).
When the limit is reached, writes are stalled (slowed) until memory is freed by a flush, rather than allowed to grow without bound. Note: does not affect durability guarantees, which are provided by the WAL.

Size values such as storage.rocksdb.cache-size and storage.rocksdb.write-buffers-limit are written as an integer with an optional, case-insensitive unit suffix: B, KB/KiB, MB/MiB, GB/GiB, or TB/TiB. A bare number is interpreted as bytes.

The units are binary (powers of 1024), so KB is identical to KiB, MB to MiB, and so on. 1gb means 1 GiB = 1,073,741,824 bytes. Fractional values (e.g. 1.5gb) are not accepted; use a smaller unit instead (e.g. 1536mb). Examples: 1gb, 512mb, 1024MiB, 2048.

Diagnostics

TypeDB optionally reports anonymous diagnostics to guide the development and optimisation of TypeDB. This data includes unexpected errors and occasional system status updates for number and size of databases, as well as numbers of transactions and queries executed per hour.

To see what information is being reported, enable and access the monitoring Web page of the server (e.g. localhost:4104/diagnostics?format=json).

See Diagnostics monitoring endpoint for the full list of Prometheus metrics exposed and how to scrape them.

Diagnostics

diagnostics.reporting.metrics

Enable usage metrics reporting by setting a boolean flag. Default value: true.

diagnostics.reporting.errors

Enable critical error reporting by setting a boolean flag. Default value: true.

diagnostics.monitoring.enable

Enable a diagnostics monitoring HTTP endpoint by setting a boolean flag. Default value: true.

diagnostics.monitoring.port

Port on which to expose the diagnostics monitoring endpoint. Default value: 4104.

Clustering (TypeDB Enterprise)

These options exist only in TypeDB Enterprise distributions, where they configure a server as a member of a cluster. TypeDB Cloud manages them for you.

A clustered server must be given a replica id, a clustering address, a deployment id, and advertise addresses; the other options are optional. The shipped server/config.yml holds localhost placeholders for all of them (replica 1, deployment id test, addresses on 127.0.0.1): override them for any real deployment. A server only creates a new cluster when started with --initialize.create-cluster=true; otherwise it waits to be registered into an existing one. For example, the first server of a new cluster can be started with:

typedb server \
    --diagnostics.deployment-id=my-cluster \
    --server.clustering.id=1 \
    --server.clustering.address=10.0.0.1:1730 \
    --server.advertise-address=10.0.0.1:1729 \
    --server.http.advertise-address=http://10.0.0.1:8000 \
    --server.admin.enabled=true \
    --initialize.create-cluster=true

Clustering

server.clustering.id

Replica id of this server: a positive integer, unique within the cluster. Must be set.

server.clustering.address

Host and port this server listens on for replication, and that the other replicas use to reach it. Must be set. The shipped config.yml uses port 1730.

server.advertise-address, server.http.advertise-address

The addresses clients connect to this server at, and are redirected to when it is the primary (see Listen vs. advertise addresses). Must be set in a cluster (the HTTP one only while HTTP is enabled).

diagnostics.deployment-id

Name of the cluster, used in diagnostics. Must be set; give all replicas the same one.

storage.clustering-directory

Directory for the replication log and cluster state. The shipped config.yml sets clustering, which resolves to server/clustering in the distribution; without the option, it is <data-directory>/../clustering. When you move the data directory, set this option too, and keep both on durable storage.

initialize.create-cluster

Allow this server to create a new cluster on its first start. Only replica 1 can do so. Ignored while the server has cluster state; remove it after the first start, so that a server restarted on empty storage does not create a new, separate cluster. Default value: false.

initialize.migrate-ce.enabled

Allow this server to migrate an existing TypeDB CE data directory in place into a new cluster (see Migrating a TypeDB CE server into a cluster). Requires initialize.create-cluster and replica id 1. Default value: false.

initialize.migrate-ce.retain-ce-backup

Keep the pre-migration copy of the data in .backup inside the data directory. When false, it is deleted once the migration has been verified. Default value: true.

Clustering encryption

server.clustering.encryption.enabled

Enable mutual TLS between replicas. Default value: false.

server.clustering.encryption.certificate

This replica’s certificate in PEM format. Must be supplied if clustering encryption is enabled.

server.clustering.encryption.certificate-key

This replica’s private key. Must be supplied if clustering encryption is enabled.

server.clustering.encryption.ca-certificate

CA certificate in PEM format that signs the replicas' certificates; every replica verifies its peers against it. Must be supplied if clustering encryption is enabled: without it, the replicas cannot connect to each other.

Logging

You can configure the directory that TypeDB uses for server logs.

Logging

logging.directory

Path to the server logs directory. Defaults to within the server distribution under server/logs.

Host machine configuration

This section describes recommended changes to the host OS.

Open file limit

To support large data volumes, it is important to check the open file limit the operating system imposes. Some Unix distributions default to 1024 open file descriptors. This can be checked with the following command:

ulimit -n

We recommend this is increased to at least 50 000.

Memory usage

The resident memory of a TypeDB server is dominated by the two shared RocksDB pools configured under storage.rocksdb, plus transactional and query execution memory.

  • Block cache (storage.rocksdb.cache-size, default 1gb) — caches uncompressed data blocks read from disk so that hot reads are served from memory. Increasing this generally improves read performance.

  • Write buffers (storage.rocksdb.write-buffers-limit, default 512mb) — hold writes in memory as they are flushed to disk. Hitting the limit causes write slowdowns as memory is cleared. Increasing this generally improves bulk loading performance but rarely affects low throughput occasional writes.

Both storage.rocksdb limits are server-wide totals, so they do not need to be scaled up for each additional database. They should instead be sized relative to the host’s total RAM and the active working set across all databases.

Working, dynamically allocated memory is also required for TypeDB’s transactional write buffers, query execution working space, and the OS page cache. The easiest way to keep these predictable is to try to use smaller rather than larger write transactions.

As rough guidance for a dedicated host:

  • To improve read performance, increase storage.rocksdb.cache-size so that the working set fits in cache. As a minimum, aim for at least 5% of the on-disk data size across all databases to fit in the block cache.

  • Avoid configuring cache-size + write-buffers-limit close to the host’s total RAM as this leaves little room for the rest of the server’s working set.

  • Increase storage.rocksdb.write-buffers-limit for sustained, write-heavy workloads if you observe write stalls; the limit trades memory for write throughput.

Server memory consumption can be observed live via the server_resources_count{kind="memoryUsedInBytes"} metric on the diagnostics monitoring endpoint — see Server resource usage.

For LLMs & AI agents: this page as Markdown · llms.txt · llms-full.txt (TypeQL summary)