S3-compatible object storage · Rust
Object storage that speaks S3. Metadata that is a database.
TessariDB S3 keeps object bytes erasure-coded on your nodes, across zones and across regions, and keeps every bucket, key and version in TessariDB. Unmodified S3 clients talk to it as they would talk to S3.
docker pull tessaridb/s3
The design in three lines
Two kinds of state, each kept where it belongs.
Metadata is a database
Every bucket, key, version, upload and policy is a record in TessariDB. Listing order, conditional writes and the commit of an object are its transactions and indexes, not a second store kept beside it.
Bytes stay on your drives
Object bytes never enter the metadata. They are written in 1 MiB blocks, each with a BLAKE3 hash checked on every read, erasure-coded across nodes, zones and regions.
What it does not do, it refuses
All 116 operations of the S3 model are dispatched by name. One that is not implemented answers NotImplemented. It is never routed to a neighbour that happens to share a path.
- PUT /media/a.jpgSigV4 ✓ · SHA-256 ✓ · CRC64NVME ✓200 OK
- PUT /media/b.jpgbody differs from its declared hash400 BadDigest
- PUT /media?websiteoperation not implemented501 NotImplemented
- GET /media/a.jpgsignature from another secret403 SignatureDoesNotMatch
Erasure coding
Lose a node. Keep reading.
An object is cut into k data and m parity shards, one per node, never more of them in one zone than the parity can lose. A write is acknowledged only when it is durable on its quorum; a read takes any k shards that verify; a background pass rewrites what went missing.
- k + m
- up to 16 shards
- write quorum
- k, or k + 1 when k = m
- every block
- BLAKE3, checked on read
Regions
Zones inside a region. Regions across the map.
Each region is a whole cluster with its own quorum and its own TessariDB members, so a client in Frankfurt is answered from Frankfurt. A bucket has a home region and replicates to the regions its rules name, after the home quorum has already said yes.
The S3 surface
The parts of S3 people actually run.
Objects to 5 GiB per PUT
Multipart beyond that, CopyObject and ranges
Versioning
Every version kept, delete markers, reads by version id
Object Lock
Retention and legal hold, enforced where data is released
Lifecycle
Expiry, noncurrent versions, abandoned uploads
Notifications
Into a TessariDB topic by default, Kafka or a webhook
Renditions
JPEG, PNG, WebP, AVIF; MP4 and WebM with posters
Quotas
Bytes and objects per bucket, checked on every write
One-key uploads
A credential that can write exactly one object
The console
An operator console that keeps a record.
Buckets and objects, users and keys shown once, grants, quotas, media rules and the cluster layout, on a listener of its own. Sign in with an access key or through your identity provider with a second factor. Every change and every download is recorded with the reason the operator gave.
More of the console →
Start
One compose file. Then your first bucket.
The image carries the server and nothing else; the compose file runs it beside the TessariDB node that holds its metadata, and creates the server’s own database account on the way.
docker compose up -d --wait
aws --endpoint-url http://127.0.0.1:9100 s3 mb s3://first
aws --endpoint-url http://127.0.0.1:9100 s3 cp ./photo.jpg s3://first/
aws --endpoint-url http://127.0.0.1:9100 s3 ls s3://first