Releases · typedb/typedb

Download from TypeDB Package Repository:

Pull the Docker image:

docker pull typedb/typedb:3.11.5

-## Breaking changes
This release breaks backwards compatibility.
This version is only compatible with TypeDB driver versions >= 3.11.0.
Connections from older drivers will be rejected.

New Features

Print TypeDB Studio link and Console command on server startup

Adds clickable/runnable connect hints to the server startup output:
```
  To connect with TypeDB Studio, open: https://studio.typedb.com/connect?address=http://localhost:8000&username=admin
  To connect with TypeDB Console, run: typedb console --address localhost:1729 --tls-disabled --username admin`
```
Both substitute localhost when the listener binds to an unspecified address (0.0.0.0 / [::]). The Studio scheme and Console invocation follow the encryption setting; the Studio link is omitted if the HTTP endpoint is disabled.

Add default advertise-address retrieved from listen-address

Remove pre-inserted advertise-address values from server endpoints configuration. Instead, auto-generate the advertise addresses based on the listen addresses following these rules:

if the listen address is an unspecified address (0.0.0.0), substitute the IP with loopback 127.0.0.1, preserving the original port -- this allows the clients to use 127.0.0.1 instead of 0.0.0.0 for connections, which is usually the intention;
otherwise, use the listen address for advertising as is.

This reduces the amount of fields required for modifications in case the user wants to change the default server ports and helps avoid sudden misconfigurations while operating with local servers.

Nothing changed for default configuration:

./typedb server

=====================================================================================
     ________ __      __ _____    _______  _____    _____       _______  _______
    |__    __|\  \  /  /|   _  \ |   _   ||   _  \ |   _  \    |   _   ||   _   |
       |  |    \  \/  / |  | |  ||  | |__||  | |  ||  | |  |   |  | |  ||  | |__|
       |  |     \    /  |  |/  / |  |___  |  | |  ||  |/  /    |  | |__||  |___
       |  |      |  |   |   __/  |   ___| |  | |  ||   _  \    |  |  __ |   ___|
       |  |      |  |   |  |     |  |  __ |  | |  ||  | |  |   |  | |  ||  |  __
       |  |      |  |   |  |     |  |_|  ||  |/  / |  |/  /    |  |_|  ||  |_|  |
       |__|      |__|   |__|     |_______||_____/  |_____/     |_______||_______|

=====================================================================================

Running TypeDB CE 3.10.4 in development mode.
Serving:
  gRPC:  0.0.0.0:1729 (connect via 127.0.0.1:1729)
  HTTP:  0.0.0.0:8000 (connect via 127.0.0.1:8000)
  Admin: 127.0.0.1:1728 (localhost only)
TLS: disabled
  WARNING: TLS NOT ENABLED. Credentials are transmitted unencrypted in plaintext.
  Drivers must be configured to connect *without TLS*.

Improved query profiler

We implement a real nested query profiling structure, which correctly captures sub-pattern timings and executions and eliminates redundant printing.
Extend TypeDB address configuration and reorganize TypeDB services for better extensibility, incl. clusters

Introduce better extensibility to TypeDB CE, enabling TypeDB services to be extended and modified by distributions with additional functionality (e.g., clustered distributions for TypeDB Enterprise/Cloud).

User-facing
- Change server configuration. Rename server.address and server.http.address to listen-addresses (address aliases are still accepted for backwards compatibility). Add advertise-address configuration for both gRPC and HTTP endpoints, distinguishing the address the server binds to from the address clients use to connect (address advertised to the clients). Supports NAT, reverse proxy, and load balancer deployments. Specifying both listen-address and address will be rejected by the system.
- Add an admin CLI tool (typedb admin) bundled with all distributions. The admin tool communicates with the server through a localhost-only gRPC endpoint (default port 1728). Supports interactive REPL mode, one-shot (--command), and script (--script) execution modes. Commands: server version, server status, help, exit.
- Add server.admin configuration section (default: enabled on port 1728).
- Restructure server startup output to a multi-line format showing each endpoint (gRPC, HTTP, Admin) with TLS status:
```
=====================================================================================
     ________ __      __ _____    _______  _____    _____       _______  _______
    |__    __|\  \  /  /|   _  \ |   _   ||   _  \ |   _  \    |   _   ||   _   |
       |  |    \  \/  / |  | |  ||  | |__||  | |  ||  | |  |   |  | |  ||  | |__|
       |  |     \    /  |  |/  / |  |___  |  | |  ||  |/  /    |  | |__||  |___
       |  |      |  |   |   __/  |   ___| |  | |  ||   _  \    |  |  __ |   ___|
       |  |      |  |   |  |     |  |  __ |  | |  ||  | |  |   |  | |  ||  |  __
       |  |      |  |   |  |     |  |_|  ||  |/  / |  |/  /    |  |_|  ||  |_|  |
       |__|      |__|   |__|     |_______||_____/  |_____/     |_______||_______|

=====================================================================================

Running TypeDB CE 3.8.3 in development mode.
Serving:
  gRPC:  0.0.0.0:1729 (connect via 127.0.0.1:1729)
  HTTP:  0.0.0.0:8000 (connect via http://127.0.0.1:8000)
  Admin: 127.0.0.1:1728 (localhost only)
TLS: disabled
  WARNING: TLS NOT ENABLED. Credentials are transmitted unencrypted in plaintext.
  Drivers must be configured to connect *without TLS*.
```
Development
- Expose config extensibility for distribution-specific settings. Cluster distributions need to parse additional config sections (e.g., server.clustering) from the same YAML file without modifying the base Config struct.
- Add server_version and server_status RPCs to the admin protocol, returning distribution info and endpoint addresses.
- Restructure the server package, introducing Operators that serve as a middleware between network services and inner TypeDB components (DatabaseManager, UserManager, etc.).
- Introduce ErrorResponseCategory for mapping server state errors to appropriate gRPC and HTTP status codes and HTTP 307 redirect support (currently cannot be used in TypeDB for most of the endpoints due to local-only authentication -- instead, an additional AuthenticatedRedirect is introduced).
- Add close signals for TransactionServices to extend the ability of the system to interrupt existing transactions without shutting down.

Bugs Fixed

Compress the content of docker images

Reduce the size of the Docker image x2 (93 MB -> 53 MB prod, 361 MB -> 141 MB snapshot) by gzipping its layers explicitly in the Bazel configuration.

This change returns the size of the Docker image to the values of the pre-Bazel 8 releases.
Fix connection-level GOAWAY errors under load

Drivers that sustain transaction churn over a single TypeDB driver connection (e.g. several worker threads opening/committing/closing many small write transactions in a row) eventually saw every in-flight request fail at the same moment with h2 protocol error: too_many_internal_resets / broken pipe. Server logs showed:
```
WARN h2/proto/streams/streams.rs:1629:
    locally-reset streams reached limit (1024)
```
followed by GOAWAY ENHANCE_YOUR_CALM. The server itself never panicked however,the gRPC connection was poisoned.
QueryCache tracks statistics & schema commit to avoid caching outdated plans
Updates the QueryCache to explicitly track validity requirements and validate insert calls. By tracking the sequence_number of the latest schema commit, we avoid #7787. By tracking statistics, we avoid #7790
Rewrite reused producible variables in transform phase
Introduces a transformation step which rewrites constraints so the variables bound by it are unique.
E.g.: $r links (some-role: $r); is rewritten to $_i links (some-role: $r); $r is $_i;

Code Refactors

Eagerly free inputs of steps which are finished executing
Frees fully consumed FixedBatchIterators from the IntersectionExecutor to save memory on long pipelines with few answers.
Refactor annotation phase to group annotation context & running variable annotations
We reduce the number of arguments in functions in the annotation phase, by grouping related arguments together in structures.

Other Improvements

Update console artifact to use empty adverise address

Update console artifact to use an empty adverise address
Remove default advertised address

Return empty advertised server address (both grpc and http) in case it's not specified instead of using a default value.

This change lets the clients to understand when the server does not enforce any address for connections and make independent decisions. It is especially important in cases of connecting to a docker container or a proxy, when the server used to return a not accessible address, which the client eagerly used and failed to connect regardless of the correctness of the connection address provided by the user.
Prepare release 3.11.1
Bump version & prepare release notes
Make studio link a constant
Escalate concurrent key and uniqueq writes to transaction failure#7800 (#7800)
Disable all warnings on optional return mismatches
Disable all warnings on optional return ...

Download from TypeDB Package Repository:

Distributions for 3.11.0-rc1

Pull the Docker image:

docker pull typedb/typedb:3.11.0-rc1

Breaking changes

This release breaks backwards compatibility.
This version is only compatible with TypeDB driver versions >= 3.11.0.
Connections from older drivers will be rejected.

New Features

Print TypeDB Studio link and Console command on server startup

Adds clickable/runnable connect hints to the server startup output:
```
  To connect with TypeDB Studio, open: https://studio.typedb.com/connect?address=http://localhost:8000&username=admin
  To connect with TypeDB Console, run: typedb console --address localhost:1729 --tls-disabled --username admin`
```
Both substitute localhost when the listener binds to an unspecified address (0.0.0.0 / [::]). The Studio scheme and Console invocation follow the encryption setting; the Studio link is omitted if the HTTP endpoint is disabled.

Add default advertise-address retrieved from listen-address

Remove pre-inserted advertise-address values from server endpoints configuration. Instead, auto-generate the advertise addresses based on the listen addresses following these rules:

if the listen address is an unspecified address (0.0.0.0), substitute the IP with loopback 127.0.0.1, preserving the original port -- this allows the clients to use 127.0.0.1 instead of 0.0.0.0 for connections, which is usually the intention;
otherwise, use the listen address for advertising as is.

This reduces the amount of fields required for modifications in case the user wants to change the default server ports and helps avoid sudden misconfigurations while operating with local servers.

Nothing changed for default configuration:

./typedb server

=====================================================================================
     ________ __      __ _____    _______  _____    _____       _______  _______
    |__    __|\  \  /  /|   _  \ |   _   ||   _  \ |   _  \    |   _   ||   _   |
       |  |    \  \/  / |  | |  ||  | |__||  | |  ||  | |  |   |  | |  ||  | |__|
       |  |     \    /  |  |/  / |  |___  |  | |  ||  |/  /    |  | |__||  |___
       |  |      |  |   |   __/  |   ___| |  | |  ||   _  \    |  |  __ |   ___|
       |  |      |  |   |  |     |  |  __ |  | |  ||  | |  |   |  | |  ||  |  __
       |  |      |  |   |  |     |  |_|  ||  |/  / |  |/  /    |  |_|  ||  |_|  |
       |__|      |__|   |__|     |_______||_____/  |_____/     |_______||_______|

=====================================================================================

Running TypeDB CE 3.10.4 in development mode.
Serving:
  gRPC:  0.0.0.0:1729 (connect via 127.0.0.1:1729)
  HTTP:  0.0.0.0:8000 (connect via 127.0.0.1:8000)
  Admin: 127.0.0.1:1728 (localhost only)
TLS: disabled
  WARNING: TLS NOT ENABLED. Credentials are transmitted unencrypted in plaintext.
  Drivers must be configured to connect *without TLS*.

Improved query profiler

We implement a real nested query profiling structure, which correctly captures sub-pattern timings and executions and eliminates redundant printing.
Extend TypeDB address configuration and reorganize TypeDB services for better extensibility, incl. clusters

Introduce better extensibility to TypeDB CE, enabling TypeDB services to be extended and modified by distributions with additional functionality (e.g., clustered distributions for TypeDB Enterprise/Cloud).

User-facing
- Change server configuration. Rename server.address and server.http.address to listen-addresses (address aliases are still accepted for backwards compatibility). Add advertise-address configuration for both gRPC and HTTP endpoints, distinguishing the address the server binds to from the address clients use to connect (address advertised to the clients). Supports NAT, reverse proxy, and load balancer deployments. Specifying both listen-address and address will be rejected by the system.
- Add an admin CLI tool (typedb admin) bundled with all distributions. The admin tool communicates with the server through a localhost-only gRPC endpoint (default port 1728). Supports interactive REPL mode, one-shot (--command), and script (--script) execution modes. Commands: server version, server status, help, exit.
- Add server.admin configuration section (default: enabled on port 1728).
- Restructure server startup output to a multi-line format showing each endpoint (gRPC, HTTP, Admin) with TLS status:
```
=====================================================================================
     ________ __      __ _____    _______  _____    _____       _______  _______
    |__    __|\  \  /  /|   _  \ |   _   ||   _  \ |   _  \    |   _   ||   _   |
       |  |    \  \/  / |  | |  ||  | |__||  | |  ||  | |  |   |  | |  ||  | |__|
       |  |     \    /  |  |/  / |  |___  |  | |  ||  |/  /    |  | |__||  |___
       |  |      |  |   |   __/  |   ___| |  | |  ||   _  \    |  |  __ |   ___|
       |  |      |  |   |  |     |  |  __ |  | |  ||  | |  |   |  | |  ||  |  __
       |  |      |  |   |  |     |  |_|  ||  |/  / |  |/  /    |  |_|  ||  |_|  |
       |__|      |__|   |__|     |_______||_____/  |_____/     |_______||_______|

=====================================================================================

Running TypeDB CE 3.8.3 in development mode.
Serving:
  gRPC:  0.0.0.0:1729 (connect via 127.0.0.1:1729)
  HTTP:  0.0.0.0:8000 (connect via http://127.0.0.1:8000)
  Admin: 127.0.0.1:1728 (localhost only)
TLS: disabled
  WARNING: TLS NOT ENABLED. Credentials are transmitted unencrypted in plaintext.
  Drivers must be configured to connect *without TLS*.
```
Development
- Expose config extensibility for distribution-specific settings. Cluster distributions need to parse additional config sections (e.g., server.clustering) from the same YAML file without modifying the base Config struct.
- Add server_version and server_status RPCs to the admin protocol, returning distribution info and endpoint addresses.
- Restructure the server package, introducing Operators that serve as a middleware between network services and inner TypeDB components (DatabaseManager, UserManager, etc.).
- Introduce ErrorResponseCategory for mapping server state errors to appropriate gRPC and HTTP status codes and HTTP 307 redirect support (currently cannot be used in TypeDB for most of the endpoints due to local-only authentication -- instead, an additional AuthenticatedRedirect is introduced).
- Add close signals for TransactionServices to extend the ability of the system to interrupt existing transactions without shutting down.

Bugs Fixed

Compress the content of docker images

Reduce the size of the Docker image x2 (93 MB -> 53 MB prod, 361 MB -> 141 MB snapshot) by gzipping its layers explicitly in the Bazel configuration.

This change returns the size of the Docker image to the values of the pre-Bazel 8 releases.
Fix connection-level GOAWAY errors under load

Drivers that sustain transaction churn over a single TypeDB driver connection (e.g. several worker threads opening/committing/closing many small write transactions in a row) eventually saw every in-flight request fail at the same moment with h2 protocol error: too_many_internal_resets / broken pipe. Server logs showed:
```
WARN h2/proto/streams/streams.rs:1629:
    locally-reset streams reached limit (1024)
```
followed by GOAWAY ENHANCE_YOUR_CALM. The server itself never panicked however,the gRPC connection was poisoned.
QueryCache tracks statistics & schema commit to avoid caching outdated plans
Updates the QueryCache to explicitly track validity requirements and validate insert calls. By tracking the sequence_number of the latest schema commit, we avoid #7787. By tracking statistics, we avoid #7790
Rewrite reused producible variables in transform phase
Introduces a transformation step which rewrites constraints so the variables bound by it are unique.
E.g.: $r links (some-role: $r); is rewritten to $_i links (some-role: $r); $r is $_i;

Code Refactors

Eagerly free inputs of steps which are finished executing
Frees fully consumed FixedBatchIterators from the IntersectionExecutor to save memory on long pipelines with few answers.
Refactor annotation phase to group annotation context & running variable annotations
We reduce the number of arguments in functions in the annotation phase, by grouping related arguments together in structures.

Other Improvements

Escalate concurrent key and unique writes to transaction failure#7800 (#7800)
Disable all warnings on optional return mismatches
Disable all warnings on optional return mismatches, till the spec is finalised

Download from TypeDB Package Repository:

Distributions for 3.10.4

Pull the Docker image:

docker pull typedb/typedb:3.10.4

New Features

Bugs Fixed

Poll for server readiness in assembly fail point tests

Fix nondeterministic failures in the failpoints test.
Fix flaky statistics underflow

We fix a flaky (occasional concept bdd failures) test due to panics in statistics counting. In particular, it occurred in schema transactions that wrote both deleted types and their instances. By doing this in the wrong order, we got an underflow panic.

We also make the server resilient to underflow panics/crashes by logging an error to the server log and sentry (if enabled) with a new macro. We consider this a 'tolerable' error which shouldn't get you into a crash situation.

Code Refactors

Add tests for statistics synchronization

Add more statistics integration tests, as well as a new "load" test, which does a small concurrent, batched load and does a reboot, verifying that all statistics are counted correctly.
Reject query pipelines exceeding 1000 stages

Add MAX_PIPELINE_STAGES limit enforced in translate_pipeline, covering read, write, and analyse paths. New QueryError::PipelineStagesLimitExceeded variant reports the offending stage count.
Checkpoint statistics after startup recovery

Improve subsequent boot time by checkpointing statistics on reboot. This in particular alleviates slow bootup caused by large commit records in the WAL that may be scanned as part of the initial synchroniziation process. Without this change, the server pays the same cost of scanning data records on every reboot, until a "large enough" modification of the data occurs.
Optimize CI build job by reducing cached artifacts download

We use the --remote_download_minimal in the ci config in Bazel, which reduces the number of artifacts downloaded during a build job in FactoryCI.

In particular, this speeds up jobs where little/nothing has changed by hugely reducing the amount of data downloaded. It could also speed up test jobs by reducing number of downloaded artifacts, but the effects seem to be less dramatic.

Have observed a build job of around 8-12 minutes now, instead of up to 20 or 30.

Other Improvements

Update Rust dependencies
Remove parallelism and memory options from .bazelrc
Bazel java runtime is hermitic (remote) - used for notes creation

This is an alpha release for CLUSTERED TypeDB 3.x. Do not use this as a stable version of TypeDB.
Instead, reference a non-alpha release of the same major and minor versions.

Download from TypeDB Package Repository:

Distributions for 3.10.0-alpha-1

Pull the Docker image:

docker pull typedb/typedb:3.10.0-alpha-1

New Features

Extend TypeDB address configuration

Introduce better extensibility to TypeDB CE, enabling TypeDB services to be extended and modified by distributions with additional functionality (e.g., clustered distributions for TypeDB Enterprise/Cloud).

Change server configuration. Rename server.address and server.http.address to listen-addresses (address aliases are still accepted for backwards compatibility). Add advertise-address configuration for both gRPC and HTTP endpoints, distinguishing the address the server binds to from the address clients use to connect (address advertised to the clients). Supports NAT, reverse proxy, and load balancer deployments. Specifying both listen-address and address will be rejected by the system.
Add an admin CLI tool (typedb admin) bundled with all distributions. The admin tool communicates with the server through a localhost-only gRPC endpoint (default port 1728). Supports interactive REPL mode, one-shot (--command), and script (--script) execution modes. Commands: server version, server status, help, exit.
Add server.admin configuration section (default: enabled on port 1728).
Restructure server startup output to a multi-line format showing each endpoint (gRPC, HTTP, Admin) with TLS status:

=====================================================================================
     ________ __      __ _____    _______  _____    _____       _______  _______
    |__    __|\  \  /  /|   _  \ |   _   ||   _  \ |   _  \    |   _   ||   _   |
       |  |    \  \/  / |  | |  ||  | |__||  | |  ||  | |  |   |  | |  ||  | |__|
       |  |     \    /  |  |/  / |  |___  |  | |  ||  |/  /    |  | |__||  |___
       |  |      |  |   |   __/  |   ___| |  | |  ||   _  \    |  |  __ |   ___|
       |  |      |  |   |  |     |  |  __ |  | |  ||  | |  |   |  | |  ||  |  __
       |  |      |  |   |  |     |  |_|  ||  |/  / |  |/  /    |  |_|  ||  |_|  |
       |__|      |__|   |__|     |_______||_____/  |_____/     |_______||_______|

=====================================================================================

Running TypeDB CE 3.8.3 in development mode.
Serving:
  gRPC:  0.0.0.0:1729 (connect via 127.0.0.1:1729)
  HTTP:  0.0.0.0:8000 (connect via http://127.0.0.1:8000)
  Admin: 127.0.0.1:1728 (localhost only)
TLS: disabled
  WARNING: TLS NOT ENABLED. Credentials are transmitted unencrypted in plaintext.
  Drivers must be configured to connect *without TLS*.

Reorganize TypeDB services for better extensibility

Expose config extensibility for distribution-specific settings. Cluster distributions need to parse additional config sections (e.g., server.clustering) from the same YAML file without modifying the base Config struct.
Add server_version and server_status RPCs to the admin protocol, returning distribution info and endpoint addresses.
Restructure the server package, introducing Operators that serve as a middleware between network services and inner TypeDB components (DatabaseManager, UserManager, etc.).
Introduce ErrorResponseCategory for mapping server state errors to appropriate gRPC and HTTP status codes and HTTP 307 redirect support (currently cannot be used in TypeDB for most of the endpoints due to local-only authentication -- instead, an additional AuthenticatedRedirect is introduced).
Add close signals for TransactionServices to extend the ability of the system to interrupt existing transactions without shutting down.

Download from TypeDB Package Repository:

Distributions for 3.10.3

Pull the Docker image:

docker pull typedb/typedb:3.10.3

New Features

Optional function returns are checked and print WARN log lines
Optional function returns are checked and any errors result in warnings being printed to the log. This is temporary to provide a path to non-breaking update and will be escalated to query-compilation errors in a future release.

The following cases are checked:
- A function which returns an optional variable is not declared as doing so.
- A variable being assigned an optional return value is not marked with ?
- A variable which was assigned an optional value is re-used in the same stage (subject to the same rules as regular optional variables).

Bugs Fixed

Fix statistics counting

We fix one tracking error that means that statistics can still on rare occasions skip records that are being counted.-

Code Refactors

Other Improvements

Download from TypeDB Package Repository:

Distributions for 3.10.2

Pull the Docker image:

docker pull typedb/typedb:3.10.2

New Features

Bugs Fixed

Fix distinct stage stack overflow

Distinct stages relied on recursion instead of a loop, which could rapidly lead to stack overflows. We now use a simple loop instead.
Fix statistics records reading

We fix a bug in statistics synchronization that led to out-of-sync statistics, which ultimately led to bad query planning.

Code Refactors

Other Improvements

Download from TypeDB Package Repository:

Distributions for 3.10.1

Pull the Docker image:

docker pull typedb/typedb:3.10.1

New Features

Optimize transaction open - +240% read-write throughput

TypeDB's history versioning architecture, combined with the desire to keep full external causality, means that opening a transaction may have to wait for transactions that committed to be 'caught up to' by the visible version number (watermark).

We optimize this by changing to a the earliest version number that retains causality without needing client coorperation (most recent fully committed snapshot) instead of the most recently validated (but not yet KV-persisted, or ack'ed) version number. This leads to shorter wait times while the watermark catches up, speeding up in particular highly parallelized data write transactions by about 5%.

  300k ops, 3 runs per branch (bench-opt-pureinsert / bench-master-pureinsert)
  Threads   Batch    opt mean    ±sd     master mean    ±sd      Delta      p
        2      10      7,759    420         7,695      416      +0.8%   0.85
        4      10     14,429    286        14,173    1,194      +1.8%   0.72
        8      10     24,343    557        22,851      415      +6.5%   <0.001  ***
       16      10     34,663  1,861        29,342    1,006     +18.1%   <0.001  ***
        2     100     18,026    337        17,821      523      +1.1%   0.57
        4     100     33,414    673        31,281    1,208      +6.8%   0.008   **
        8     100     55,590  2,131        52,981    2,002      +4.9%   0.12
       16     100     61,629  2,666        58,704    7,699      +5.0%   0.53

Secondary throughput improvements

The secondary consequence of this change are highly interesting. In a mixed 50/50 read and write workload, we increase total system query throughput by 2.4x. Note that this and all tests were on small scale data, so mostly were in-memory (larger scale test that hit disk would also be interesting to verify)

(batch=1, 100k ops, 8 thread total)
opt 4W+4R    master 4W+4R    Delta
  Write ops/s          1,056          1,119     -5.6%
  Read ops/s           6,881          2,117   +225.1%
  Total ops/s          7,937          3,236   +145.3%

This occurs because the reader threads are now spending much less time blocking & waiting for the watermark, and much more time executing.

If we increase thread counts further, we find that reader threads end up starving the writer threads, as the 10 core machine is fully subscribed:

opt 8W+8R    master 8W+8R    Delta
  Write ops/s            707          1,892    -62.6%
  Read ops/s          11,191          4,073   +174.7%
  Total ops/s         11,898          5,965    +99.5%

To confirm the hypothesis that the write performance reduction is due to total machine oversubscription, we test that pure reader threads are able to fully saturate the CPU. We did an experiment showing ops performed in a fixed time period (10 seconds) with an increasing number of threads:

Reader CPU Saturation Test (10 CPU cores, 10s per config)

  Threads   Total reads/s   Per-thread reads/s   Scaling
        1          1,720              1,720        1.0x
        2          3,755              1,877        2.2x
        4          7,391              1,848        4.3
        8         14,475              1,809        8.4x
       10         16,361              1,636        9.5x  (peak)
       12         15,879              1,323        9.2x  (declining)
       16         12,073                755        7.0x  (worse than 8!)

So we can confirm that pure reader threads can fully saturate the CPU, and over-parallelizing penalizes and drops throughput! We conclude that write throughput drop in the previous test with 8 read and 8 write threads is because the 8 reader threads are essentially fully saturating 8 cores on their own, and the 8 writer threads are competing for resources. We should theoretically see similar behaviour if we had a 2 core machine with 8 writer threads.

Test for commit validation cost:

Since we hypothesize that commit validation could take slightly longer, but we spend less time opening transactions, there is likely a point where larger commits can slow down commit validation which can slow down throughput overall. In this test, we write larger and larger batches of straight inserts, which still must be serialized and validated against each other to look for conflicts. (Note: without conflicts these validations can run and finish, without needing to depend on each others' validation results. However - testing with a commit that forces commit waiting doesn't show any different results).

PureInsert COMPLETE — all batch sizes, 5 runs, 300k ops

   Batch  Thr   opt mean      ±sd   CV%   mst mean      ±sd   CV%       Δ%        p
  ==========================================================================================
       1    1        332        9  2.6%        339        2  0.6%    -2.1%   0.072
       1    4      1,198       48  4.0%      1,017      122 12.0%   +17.8%   0.002   **
       1    8      2,207      110  5.0%      1,822      230 12.6%   +21.1%   <0.001  ***

     100    1      9,342      399  4.3%      9,878      588  6.0%    -5.4%   0.091
     100    4     31,241    1,185  3.8%     31,931      566  1.8%    -2.2%   0.240
     100    8     47,889    6,881 14.4%     53,577    2,334  4.4%   -10.6%   0.080

    1000    1     10,851       63  0.6%     11,141      102  0.9%    -2.6%   <0.001  ***
    1000    4     37,543      516  1.4%     39,668      557  1.4%    -5.4%   <0.001  ***
    1000    8     57,808    5,816 10.1%     64,092    1,434  2.2%    -9.8%   0.019    *

    2000    1     13,450      177  1.3%     13,542       28  0.2%    -0.7%   0.253
    2000    4     45,045    1,581  3.5%     43,756      445  1.0%    +2.9%   0.079
    2000    8     75,975      934  1.2%     76,528    1,932  2.5%    -0.7%   0.564

    4000    1     13,563      118  0.9%     13,564       55  0.4%    -0.0%   0.978
    4000    4     37,011    1,111  3.0%     37,269      960  2.6%    -0.7%   0.694
    4000    8     65,881    4,023  6.1%     60,821    9,051 14.9%    +8.3%   0.253

We see that for tiny commits (size 1), we see significant gains, but at around 1000 we see some reduction in throughput. After that, we go back to being within the noise.

Bump TypeQL to receive unicode unescaping
Escaped unicode characters can be used in TypeQL string literals. These must be of the form \uXXXX (exactly 4 hex digits), or \u{XX...X} (1 to 6 hex digits).

Bugs Fixed

Error on assigning to existing variable in a reduce stage
Error on reduce assigning to existing variable. Source errors when building functions in a Fetch clause are now propagated.

Code Refactors

Re-order block variable validation
Checks boundedness check for via input requirements before the check for boundedness via variable-categories.
Variable binding mode changes
Variable binding modes fully replace the use of scopes to determine variable binding & visibility.
Raise gRPC message size limits to 1 GB

The default tonic limit of 4 MB is too restrictive for database workloads. Query responses, fetch documents with many attributes, and export batches can legitimately exceed 4 MB. This caused client-side decode failures with: "decoded message length too large: found N bytes, the limit is: 4194304 bytes"

Set both encoding and decoding limits to 1 GB on the TypeDbServer service, matching the approach taken by other database systems eg. CockroachDB.

Other Improvements

Update Bazel rustfmt to latest nightly

We update the rules_rust rustfmt version to latest nightly available for better compatibility with local tools.
Bump typeql for parser performance improvements
Bump typeql for parser performance improvements
Non recursive executable stages

Refactor to allow long query pipelines of several hundred or thousand clauses to succeed without stack overflows.

The common case here is users writing or generating a long sequence of insert clauses.

Fixes #7719

Caveats

Using really long query pipelines causes really big slowdowns in compilation:

For 2000 chained inserts:
- translate: 1.5s
- annotate: 3.1s
- compile: 4.2s
- extract_pipeline_structure: 0.4s
- build_write_pipeline: 0.005s — negligible
All three main phases show O(n^2) growth - likely because each insert stage's output row accumulates all variables from prior stages, and every stage needs to process this growing row mapping.

Note: now at least, this is a slowdown not a crash. Follow up work should introduce a pipeline cap, for instance at say 1000 inserts and produce a useful error.
Fail point instrumentation tests

We add a suite of crash recovery tests where we ensure that TypeDB server can start back up after it crashes during a disk operation such as making a checkpoint.
Fetch TypeDB console using native_artifact_files module extension
Fetches the TypeDB console artifact using native_artifacts_files, close to how we used to with bazel 6.
Bazel 8 upgrade

Migrate TypeDB server build from Bazel 6.2 (WORKSPACE) to Bazel 8.5.1 (Bzlmod).

Download from TypeDB Package Repository:

Distributions for 3.10.0-rc3

Pull the Docker image:

docker pull typedb/typedb:3.10.0-rc3

New Features

Optimize transaction open - +240% read-write throughput

TypeDB's history versioning architecture, combined with the desire to keep full external causality, means that opening a transaction may have to wait for transactions that committed to be 'caught up to' by the visible version number (watermark).

We optimize this by changing to a the earliest version number that retains causality without needing client coorperation (most recent fully committed snapshot) instead of the most recently validated (but not yet KV-persisted, or ack'ed) version number. This leads to shorter wait times while the watermark catches up, speeding up in particular highly parallelized data write transactions by about 5%.

  300k ops, 3 runs per branch (bench-opt-pureinsert / bench-master-pureinsert)
  Threads   Batch    opt mean    ±sd     master mean    ±sd      Delta      p
        2      10      7,759    420         7,695      416      +0.8%   0.85
        4      10     14,429    286        14,173    1,194      +1.8%   0.72
        8      10     24,343    557        22,851      415      +6.5%   <0.001  ***
       16      10     34,663  1,861        29,342    1,006     +18.1%   <0.001  ***
        2     100     18,026    337        17,821      523      +1.1%   0.57
        4     100     33,414    673        31,281    1,208      +6.8%   0.008   **
        8     100     55,590  2,131        52,981    2,002      +4.9%   0.12
       16     100     61,629  2,666        58,704    7,699      +5.0%   0.53

Secondary throughput improvements

The secondary consequence of this change are highly interesting. In a mixed 50/50 read and write workload, we increase total system query throughput by 2.4x. Note that this and all tests were on small scale data, so mostly were in-memory (larger scale test that hit disk would also be interesting to verify)

(batch=1, 100k ops, 8 thread total)
opt 4W+4R    master 4W+4R    Delta
  Write ops/s          1,056          1,119     -5.6%
  Read ops/s           6,881          2,117   +225.1%
  Total ops/s          7,937          3,236   +145.3%

This occurs because the reader threads are now spending much less time blocking & waiting for the watermark, and much more time executing.

If we increase thread counts further, we find that reader threads end up starving the writer threads, as the 10 core machine is fully subscribed:

opt 8W+8R    master 8W+8R    Delta
  Write ops/s            707          1,892    -62.6%
  Read ops/s          11,191          4,073   +174.7%
  Total ops/s         11,898          5,965    +99.5%

To confirm the hypothesis that the write performance reduction is due to total machine oversubscription, we test that pure reader threads are able to fully saturate the CPU. We did an experiment showing ops performed in a fixed time period (10 seconds) with an increasing number of threads:

Reader CPU Saturation Test (10 CPU cores, 10s per config)

  Threads   Total reads/s   Per-thread reads/s   Scaling
        1          1,720              1,720        1.0x
        2          3,755              1,877        2.2x
        4          7,391              1,848        4.3
        8         14,475              1,809        8.4x
       10         16,361              1,636        9.5x  (peak)
       12         15,879              1,323        9.2x  (declining)
       16         12,073                755        7.0x  (worse than 8!)

So we can confirm that pure reader threads can fully saturate the CPU, and over-parallelizing penalizes and drops throughput! We conclude that write throughput drop in the previous test with 8 read and 8 write threads is because the 8 reader threads are essentially fully saturating 8 cores on their own, and the 8 writer threads are competing for resources. We should theoretically see similar behaviour if we had a 2 core machine with 8 writer threads.

Test for commit validation cost:

Since we hypothesize that commit validation could take slightly longer, but we spend less time opening transactions, there is likely a point where larger commits can slow down commit validation which can slow down throughput overall. In this test, we write larger and larger batches of straight inserts, which still must be serialized and validated against each other to look for conflicts. (Note: without conflicts these validations can run and finish, without needing to depend on each others' validation results. However - testing with a commit that forces commit waiting doesn't show any different results).

PureInsert COMPLETE — all batch sizes, 5 runs, 300k ops

   Batch  Thr   opt mean      ±sd   CV%   mst mean      ±sd   CV%       Δ%        p
  ==========================================================================================
       1    1        332        9  2.6%        339        2  0.6%    -2.1%   0.072
       1    4      1,198       48  4.0%      1,017      122 12.0%   +17.8%   0.002   **
       1    8      2,207      110  5.0%      1,822      230 12.6%   +21.1%   <0.001  ***

     100    1      9,342      399  4.3%      9,878      588  6.0%    -5.4%   0.091
     100    4     31,241    1,185  3.8%     31,931      566  1.8%    -2.2%   0.240
     100    8     47,889    6,881 14.4%     53,577    2,334  4.4%   -10.6%   0.080

    1000    1     10,851       63  0.6%     11,141      102  0.9%    -2.6%   <0.001  ***
    1000    4     37,543      516  1.4%     39,668      557  1.4%    -5.4%   <0.001  ***
    1000    8     57,808    5,816 10.1%     64,092    1,434  2.2%    -9.8%   0.019    *

    2000    1     13,450      177  1.3%     13,542       28  0.2%    -0.7%   0.253
    2000    4     45,045    1,581  3.5%     43,756      445  1.0%    +2.9%   0.079
    2000    8     75,975      934  1.2%     76,528    1,932  2.5%    -0.7%   0.564

    4000    1     13,563      118  0.9%     13,564       55  0.4%    -0.0%   0.978
    4000    4     37,011    1,111  3.0%     37,269      960  2.6%    -0.7%   0.694
    4000    8     65,881    4,023  6.1%     60,821    9,051 14.9%    +8.3%   0.253

We see that for tiny commits (size 1), we see significant gains, but at around 1000 we see some reduction in throughput. After that, we go back to being within the noise.

Bump TypeQL to receive unicode unescaping
Escaped unicode characters can be used in TypeQL string literals. These must be of the form \uXXXX (exactly 4 hex digits), or \u{XX...X} (1 to 6 hex digits).

Bugs Fixed

Error on assigning to existing variable in a reduce stage
Error on reduce assigning to existing variable. Source errors when building functions in a Fetch clause are now propagated.

Code Refactors

Variable binding mode changes
Variable binding modes fully replace the use of scopes to determine variable binding & visibility.
Raise gRPC message size limits to 1 GB

The default tonic limit of 4 MB is too restrictive for database workloads. Query responses, fetch documents with many attributes, and export batches can legitimately exceed 4 MB. This caused client-side decode failures with: "decoded message length too large: found N bytes, the limit is: 4194304 bytes"

Set both encoding and decoding limits to 1 GB on the TypeDbServer service, matching the approach taken by other database systems eg. CockroachDB.

Other Improvements

Bump typeql for parser performance improvements
Bump typeql for parser performance improvements
Non recursive executable stages

Refactor to allow long query pipelines of several hundred or thousand clauses to succeed without stack overflows.

The common case here is users writing or generating a long sequence of insert clauses.

Fixes #7719

Caveats

Using really long query pipelines causes really big slowdowns in compilation:

For 2000 chained inserts:
- translate: 1.5s
- annotate: 3.1s
- compile: 4.2s
- extract_pipeline_structure: 0.4s
- build_write_pipeline: 0.005s — negligible
All three main phases show O(n^2) growth - likely because each insert stage's output row accumulates all variables from prior stages, and every stage needs to process this growing row mapping.

Note: now at least, this is a slowdown not a crash. Follow up work should introduce a pipeline cap, for instance at say 1000 inserts and produce a useful error.
Fail point instrumentation tests

We add a suite of crash recovery tests where we ensure that TypeDB server can start back up after it crashes during a disk operation such as making a checkpoint.
Fetch TypeDB console using native_artifact_files module extension
Fetches the TypeDB console artifact using native_artifacts_files, close to how we used to with bazel 6.

Download from TypeDB Package Repository:

Distributions for 3.10.0-rc2

Pull the Docker image:

docker pull typedb/typedb:3.10.0-rc2

New Features

Optimize transaction open - +240% read-write throughput

TypeDB's history versioning architecture, combined with the desire to keep full external causality, means that opening a transaction may have to wait for transactions that committed to be 'caught up to' by the visible version number (watermark).

We optimize this by changing to a the earliest version number that retains causality without needing client coorperation (most recent fully committed snapshot) instead of the most recently validated (but not yet KV-persisted, or ack'ed) version number. This leads to shorter wait times while the watermark catches up, speeding up in particular highly parallelized data write transactions by about 5%.

  300k ops, 3 runs per branch (bench-opt-pureinsert / bench-master-pureinsert)
  Threads   Batch    opt mean    ±sd     master mean    ±sd      Delta      p
        2      10      7,759    420         7,695      416      +0.8%   0.85
        4      10     14,429    286        14,173    1,194      +1.8%   0.72
        8      10     24,343    557        22,851      415      +6.5%   <0.001  ***
       16      10     34,663  1,861        29,342    1,006     +18.1%   <0.001  ***
        2     100     18,026    337        17,821      523      +1.1%   0.57
        4     100     33,414    673        31,281    1,208      +6.8%   0.008   **
        8     100     55,590  2,131        52,981    2,002      +4.9%   0.12
       16     100     61,629  2,666        58,704    7,699      +5.0%   0.53

Secondary throughput improvements

The secondary consequence of this change are highly interesting. In a mixed 50/50 read and write workload, we increase total system query throughput by 2.4x. Note that this and all tests were on small scale data, so mostly were in-memory (larger scale test that hit disk would also be interesting to verify)

(batch=1, 100k ops, 8 thread total)
opt 4W+4R    master 4W+4R    Delta
  Write ops/s          1,056          1,119     -5.6%
  Read ops/s           6,881          2,117   +225.1%
  Total ops/s          7,937          3,236   +145.3%

This occurs because the reader threads are now spending much less time blocking & waiting for the watermark, and much more time executing.

If we increase thread counts further, we find that reader threads end up starving the writer threads, as the 10 core machine is fully subscribed:

opt 8W+8R    master 8W+8R    Delta
  Write ops/s            707          1,892    -62.6%
  Read ops/s          11,191          4,073   +174.7%
  Total ops/s         11,898          5,965    +99.5%

To confirm the hypothesis that the write performance reduction is due to total machine oversubscription, we test that pure reader threads are able to fully saturate the CPU. We did an experiment showing ops performed in a fixed time period (10 seconds) with an increasing number of threads:

Reader CPU Saturation Test (10 CPU cores, 10s per config)

  Threads   Total reads/s   Per-thread reads/s   Scaling
        1          1,720              1,720        1.0x
        2          3,755              1,877        2.2x
        4          7,391              1,848        4.3
        8         14,475              1,809        8.4x
       10         16,361              1,636        9.5x  (peak)
       12         15,879              1,323        9.2x  (declining)
       16         12,073                755        7.0x  (worse than 8!)

So we can confirm that pure reader threads can fully saturate the CPU, and over-parallelizing penalizes and drops throughput! We conclude that write throughput drop in the previous test with 8 read and 8 write threads is because the 8 reader threads are essentially fully saturating 8 cores on their own, and the 8 writer threads are competing for resources. We should theoretically see similar behaviour if we had a 2 core machine with 8 writer threads.

Test for commit validation cost:

Since we hypothesize that commit validation could take slightly longer, but we spend less time opening transactions, there is likely a point where larger commits can slow down commit validation which can slow down throughput overall. In this test, we write larger and larger batches of straight inserts, which still must be serialized and validated against each other to look for conflicts. (Note: without conflicts these validations can run and finish, without needing to depend on each others' validation results. However - testing with a commit that forces commit waiting doesn't show any different results).

PureInsert COMPLETE — all batch sizes, 5 runs, 300k ops

   Batch  Thr   opt mean      ±sd   CV%   mst mean      ±sd   CV%       Δ%        p
  ==========================================================================================
       1    1        332        9  2.6%        339        2  0.6%    -2.1%   0.072
       1    4      1,198       48  4.0%      1,017      122 12.0%   +17.8%   0.002   **
       1    8      2,207      110  5.0%      1,822      230 12.6%   +21.1%   <0.001  ***

     100    1      9,342      399  4.3%      9,878      588  6.0%    -5.4%   0.091
     100    4     31,241    1,185  3.8%     31,931      566  1.8%    -2.2%   0.240
     100    8     47,889    6,881 14.4%     53,577    2,334  4.4%   -10.6%   0.080

    1000    1     10,851       63  0.6%     11,141      102  0.9%    -2.6%   <0.001  ***
    1000    4     37,543      516  1.4%     39,668      557  1.4%    -5.4%   <0.001  ***
    1000    8     57,808    5,816 10.1%     64,092    1,434  2.2%    -9.8%   0.019    *

    2000    1     13,450      177  1.3%     13,542       28  0.2%    -0.7%   0.253
    2000    4     45,045    1,581  3.5%     43,756      445  1.0%    +2.9%   0.079
    2000    8     75,975      934  1.2%     76,528    1,932  2.5%    -0.7%   0.564

    4000    1     13,563      118  0.9%     13,564       55  0.4%    -0.0%   0.978
    4000    4     37,011    1,111  3.0%     37,269      960  2.6%    -0.7%   0.694
    4000    8     65,881    4,023  6.1%     60,821    9,051 14.9%    +8.3%   0.253

We see that for tiny commits (size 1), we see significant gains, but at around 1000 we see some reduction in throughput. After that, we go back to being within the noise.

Bump TypeQL to receive unicode unescaping
Escaped unicode characters can be used in TypeQL string literals. These must be of the form \uXXXX (exactly 4 hex digits), or \u{XX...X} (1 to 6 hex digits).

Bugs Fixed

Error on assigning to existing variable in a reduce stage
Error on reduce assigning to existing variable. Source errors when building functions in a Fetch clause are now propagated.

Code Refactors

Variable binding mode changes
Variable binding modes fully replace the use of scopes to determine variable binding & visibility.
Raise gRPC message size limits to 1 GB

The default tonic limit of 4 MB is too restrictive for database workloads. Query responses, fetch documents with many attributes, and export batches can legitimately exceed 4 MB. This caused client-side decode failures with: "decoded message length too large: found N bytes, the limit is: 4194304 bytes"

Set both encoding and decoding limits to 1 GB on the TypeDbServer service, matching the approach taken by other database systems eg. CockroachDB.

Other Improvements

Bump typeql for parser performance improvements
Bump typeql for parser performance improvements
Non recursive executable stages

Refactor to allow long query pipelines of several hundred or thousand clauses to succeed without stack overflows.

The common case here is users writing or generating a long sequence of insert clauses.

Fixes #7719

Caveats

Using really long query pipelines causes really big slowdowns in compilation:

For 2000 chained inserts:
- translate: 1.5s
- annotate: 3.1s
- compile: 4.2s
- extract_pipeline_structure: 0.4s
- build_write_pipeline: 0.005s — negligible
All three main phases show O(n^2) growth - likely because each insert stage's output row accumulates all variables from prior stages, and every stage needs to process this growing row mapping.

Note: now at least, this is a slowdown not a crash. Follow up work should introduce a pipeline cap, for instance at say 1000 inserts and produce a useful error.
Fail point instrumentation tests

We add a suite of crash recovery tests where we ensure that TypeDB server can start back up after it crashes during a disk operation such as making a checkpoint.
Fetch TypeDB console using native_artifact_files module extension
Fetches the TypeDB console artifact using native_artifacts_files, close to how we used to with bazel 6.

Download from TypeDB Package Repository:

Distributions for 3.8.3

Pull the Docker image:

docker pull typedb/typedb:3.8.3

New Features

Bugs Fixed

Seed variables in comparison with attribute types for type-inference
Type-inference now seeds the variables involved in comparisons with attribute types. This avoids other kinds being involved in comparisons allows simpler downstream code, avoiding errors like #7697

Code Refactors

Other Improvements

Increase posthog reporting interval to 2 hours

We increase the Posthog reporting interval to once every two hours.
Limit recovery read size when updating data statistics

We discard pre-loaded commit records when updating data statistics when the total size of data loaded from the WAL exceeds the limit (currently 1 GiB).

Releases: typedb/typedb

TypeDB 3.11.5

New Features

User-facing

Development

Bugs Fixed

Code Refactors

Other Improvements

Uh oh!

TypeDB 3.11.0-rc1

Breaking changes

New Features

User-facing

Development

Bugs Fixed

Code Refactors

Other Improvements

Uh oh!

TypeDB 3.10.4

New Features

Bugs Fixed

Code Refactors

Other Improvements

Uh oh!

TypeDB 3.10.0-alpha-1

New Features

Extend TypeDB address configuration

Reorganize TypeDB services for better extensibility

Uh oh!

TypeDB 3.10.3

New Features

Bugs Fixed

Code Refactors

Other Improvements

Uh oh!

TypeDB 3.10.2

New Features

Bugs Fixed

Code Refactors

Other Improvements

Uh oh!

TypeDB 3.10.1

New Features

Secondary throughput improvements

Test for commit validation cost:

Bugs Fixed

Code Refactors

Other Improvements

Caveats

Uh oh!

TypeDB 3.10.0-rc3

New Features

Secondary throughput improvements

Test for commit validation cost:

Bugs Fixed

Code Refactors

Other Improvements

Caveats

Uh oh!

TypeDB 3.10.0-rc2

New Features

Secondary throughput improvements

Test for commit validation cost:

Bugs Fixed

Code Refactors

Other Improvements

Caveats

Uh oh!

TypeDB 3.8.4-rc2

New Features

Bugs Fixed

Code Refactors

Other Improvements

Uh oh!