This is TeselaDB

A document database that implements the MongoDB 9.0 protocol and spreads each collection across replicated ranges.

5 min read

TeselaDB is a distributed document database. It stores BSON documents, implements the MongoDB 9.0 protocol and splits each collection into ranges replicated across the nodes of the cluster. Your applications connect with the official MongoDB drivers and with mongosh, and tools such as Compass or the Database Tools work the same, so the first contact feels a lot like connecting to one more MongoDB.

One binary, equal nodes

A single binary, teseladb, is the node, the router and the administration tool. All nodes are equal. There are no config servers or helper processes to deploy apart, because the cluster metadata lives in a Raft group spread across those same nodes. Inside each node, one thread per CPU core owns its ranges, its log and its storage. To grow, you start the binary on another machine with an enrollment token and the cluster begins to give it replicas. The same binary starts a three-node development cluster in a single process with teseladb dev.

Ranges that spread on their own

Each collection is split into key ranges. A range splits when it holds more than 64 MiB of live data or 512 MiB on disk with its versions, or when it takes too many operations. Two small, cold neighbours merge. The balancer moves replicas and leaders between nodes until load and free space even out. You choose no shard key. If you already use shard keys or zones, they keep working with MongoDB's semantics, and for a key that always grows, such as a date, an index with teselaBuckets spreads its entries over buckets. With teseladb admin ranges you can see at any time the ranges of a collection, with their bounds and their replicas.

Each range, its own Raft

Each range is a Raft group with its leader and its replicas. A write commits once a majority of the replicas of its range have it on disk. A write confirmed with w: "majority" then survives the loss of any minority of those replicas, whatever the node that goes down. If a node goes down, the ranges it led elect another leader among the remaining replicas and the drivers retry the operation in flight. Because ranges are independent, a problem in one does not slow the others.

Transactions across ranges and nodes

A transaction can touch documents of several ranges on different nodes and commits atomically, with snapshot isolation. Timestamps come from hybrid logical clocks, so there is no need for a central clock or atomic clocks. The drivers' withTransaction retries what it should, as with MongoDB. By default, a transaction is aborted after 60 seconds.

Search inside the database

Text and vector search indexes are created with the same commands as in Atlas, and $search and $vectorSearch work in the aggregation pipeline. The difference is that they live inside the database. A search sees every write confirmed before it starts, without waiting for a separate service to catch up, and the scores use the statistics of the whole collection. For vectors, the index declares numDimensions, the size of the vectors your embedding model produces. The semantic search and RAG guides set up both kinds of index with sample data.

Secure from the first start

The first node creates the cluster's certificate authority and the root user. TLS and users are on from that moment. Nodes only communicate with each other over TLS 1.3, with a certificate at both ends. Roles and privileges are MongoDB's. Applications can log in with their X.509 certificate, without a password. Encryption at rest comes in the same binary and, without a key file of yours, takes its key from the cluster PKI. One cluster can also keep several customers apart in tenants, each with its users and its databases.

For HTTP and for agents

Each node also serves a REST API described with OpenAPI and an MCP server with the MongoDB MCP Server tools. The MCP server starts read-only and each call checks the privileges of the API key that makes it. Neither changes the MongoDB protocol, so you only use them if they suit you.

What changes from MongoDB

Some features behave differently, almost always with a stronger guarantee. A unique index is unique across the cluster. A find without sort returns documents in the order of their key. What MongoDB marks as deprecated in version 9.0 is not implemented, except what drivers and mongosh still send. Each case is in Differences with MongoDB.

Where to start

Quick start with one node leaves you a node running in a few minutes. For several nodes on your machine, follow Quick start with a local cluster, and when you want to build something concrete, the guides go step by step from an orders API to a three-machine cluster with scheduled backups. Each guide starts TeselaDB from scratch with Docker, so you can follow it on your own machine.

Tags

  • product
  • MongoDB
  • cluster
All posts