Introduction
Field Manual Section 1 - Mission Briefing
Welcome to the Tank field manual. This is the quick guide for developers who want to drive, fight and survive with Tank (Table Abstraction & Navigation Kit): the Rust data layer.
In plain terms, Tank is a thin layer over your database workflow, designed for the Rust operator who needs to deploy across multiple environments without changing the kit. It doesn't matter if you are digging into a local SQLite trench, coordinating a distributed ScyllaDB cluster, or managing a Postgres stronghold, Tank provides a unified interface. You define your entities, Tank handles the ballistics.
Mission Objectives
Tank exists to implement the best possible design for an ORM written in Rust. A clean-slate approach focused on ergonomics, flexibility and broad database support.
- Async operations - Fire and forget.
- Designed to be extensible - Swap databases like changing magazines mid-battle.
- SQL and NoSQL support - One Tank, all terrains.
- Transactions abstraction - Commit on success or rollback and retreat.
- Rich type arsenal - Automatic conversions between Rust and database types.
- Optional appender API - High caliber bulk inserts.
- TLS - No open radios on this battlefield.
- Joins - Multi unit coordination.
- Raw SQL - You're never limited by the abstractions provided.
- Zero setup - Skip training. Go straight to live fire.
No-Fly Zone
- No schema migrations (just table creation and drop for fast setup).
- No implicit joins (no entities as fields, joins are explicit, every alliance is signed).
Equipment
Core Arsenal
- tank: The command vehicle, main crate to use together with a driver.
- tank-core: All the heavy machinery that makes the Tank move.
- tank-macros: Derives and helper macros.
- tank-tests: Shared integration tests for drivers.
Drivers
All the crates in this workspace share the same version.
Why Tank?
Intelligence Report: A quick recon of the battlefield revealed that while existing heavy weaponry is effective, there was a critical need for a more adaptable, cleaner design. Tank was designed from scratch to address these weaknesses.
1. Modular Architecture: Some systems rely on hardcoded enums for database support, which limits flexibility. If a backend isn't in the core list, it cannot be used. Tank is designed to be extensible: a driver can be implemented for any database (SQL or NoSQL) without touching the core library. If it can hold data, Tank can likely target it.
2. Zero Boilerplate: Field operations shouldn't require filling out forms in triplicate. Some tools force data definition twice: once in a complex DSL and again as a Rust struct. Tank keeps it simple: one struct, one definition. The macros handle table creation, selection, and insertion automatically. You can set up tables and get database communication running in just a few lines of code, all through a unified API that works the same regardless of the backend. Perfect for spinning up tests and prototypes rapidly while still scaling to production backends.
Support the Mission
Building and maintaining drivers for half a dozen different databases is a massive effort. If Tank saves your company time, infrastructure headaches, or boilerplate, please consider supporting its development.
Donations ensure that Tank stays maintained, well-tested, and gets new capabilities (like more advanced driver features) faster.
🔗 Sponsor the Commander via GitHub Sponsors
Hold the line. Maintain discipline. Tank out.