The database for Offer & Order Management.

Built for Offer & Order Management

An Offer Management System has to do three things at the speed of a shopping cart: assemble offers from many components, hold them long enough for the customer to act, and convert the chosen offer into an order without losing fidelity. An Order Management System has to do another three: store every order in its full nested glory, retrieve it sub-millisecond from anywhere in the network, and amend it without rewriting the schema every quarter.

Every one of those operations is a JSON document. None of them is a comfortable fit for a relational schema with twelve foreign-key joins per read. DocumentForge is what happens when you start from the access pattern — point lookup on offerId, range scan on createdAt, nested filter on passengers[].fareFamily — and build the storage engine to match.

The pieces of an OMS that map cleanly to DocumentForge

• Offer pool — millions of offers, each with bundles, services, ancillaries, prices, expiry. Indexed point lookup on offerId; range scans on expiresAt; nested predicates over bundles[].products[].
• Order store — the system of record. Full IATA-shaped JSON, never flattened. Indexed on orderId, passengers[].lastName, bookingReference, whatever you actually look up.
• Reference data — airports, fare families, ancillary catalogues, tax rules. Replicated to every shard so joins stay local. Hot in memory, never the bottleneck.
• Pricing & fare cache — short-TTL JSON blobs that get hammered by shopping. Direct addressing means the hash hit is the disk address. 210K QPS sustained on a laptop.
• Audit log — append-only stream of every offer, every order amendment, every state change. Sequence-numbered, replicated, durable.

Aligned with IATA Modern Airline Retailing

The IATA Modern Airline Retailing programme — Offers & Orders, NDC, ONE Order — defines the data in JSON Schema. The Offer is JSON. The Order is JSON. The Service, the Bundle, the Pax, the Price — all JSON. Forcing it through a relational ORM costs you twice: once on the way in (shred), once on the way out (rebuild). And it punishes you a third time every time IATA evolves the schema.

DocumentForge stores the Offer or Order exactly as the standard defines it. Nested arrays of passengers, journeys, services, bundles — they go in as JSON and come out as JSON. SQL queries reach into the structure with dot notation and bracket indexing — SELECT * FROM orders WHERE bundles[0].products[0].cabin = 'BUSINESS'. No mapping layer. No drift between the canonical shape and the stored shape.

Your data, your control

The Offer/Order store is the most sensitive system an airline runs. It contains every customer name, every itinerary, every payment reference, every loyalty interaction. It must not, under any circumstance, be hostage to a vendor's billing model, license audit, or hosting decision.

DocumentForge is a file on a disk you own, in a process you run, in a datacenter or cloud account you control. The binary is open source under MIT. The file format is documented. There is no licence server to phone home, no usage meter to hit a tier on, no “managed” cloud that becomes the vendor's leverage at renewal time.

• No vendor cloud lock-in. Run it where you want. Move it whenever you want. Egress is a cp.
• No opaque licensing risk. MIT. Read it once, never think about it again.
• No phone-home, no telemetry. The binary makes no network calls you didn't ask it to make.
• Read every line. ~6,500 lines of C#. An airline's own engineers can audit the whole storage engine.

Safety & durability — airline operations grade

An airline operations system can lose a record exactly never. DocumentForge takes that seriously at every layer.

• Write-ahead logging. Every mutation lands in the WAL with a CRC32 before the data file is touched. Crash mid-write, restart, replay — no torn writes.
• Per-page checksums. Silent corruption is detected on every read. A bad disk doesn't quietly mangle an Order — it raises an error.
• Logical replication. Followers replay the WAL by sequence number. Reconnect after a network blip and you catch up automatically.
• Auto-failover. If the leader goes silent, a follower promotes. Reads keep flowing.
• Planned handover. Move a leader between datacenters with zero data loss — quiesce, drain, hand over the seq number, resume.

Simplicity is a feature

Most databases are big. They have a query optimizer the size of a telephone directory, a config surface with hundreds of knobs, a plugin ecosystem that's a CVE feed waiting to happen. They are difficult to operate, difficult to reason about, and difficult to trust.

DocumentForge is small on purpose. About 6,500 lines of clean C#, organised into focused projects: Storage, Document, Index, Query, Transactions, Engine. Each one fits in a head. The whole thing builds to a single self-contained binary that runs on Windows, Linux, and macOS — no .NET runtime install required on the target machine.

From single-file to sharded fleet

Most projects start as one service, one database, one developer. DocumentForge starts there too — open a .dfdb file, start writing JSON. As the workload grows, scale by addition rather than by rewrite:

• Read scaling → add a follower. Same binary, replication-secret pair, point at the leader.
• Write throughput / dataset size → add a shard. Consistent-hash router places documents by orderId (or any key you pick).
• Online rebalance → add or drop shards while clients keep reading and writing. No maintenance window.
• Reference collections everywhere → small lookup tables (airports, fare families) replicate to every shard so JOINs stay local.

The same binary, the same SQL, the same data file format from day one to day one-thousand. There is no “rewrite when you outgrow it” moment.

When DocumentForge fits — and when it doesn't

Pick the right tool. We're honest about both ends.

Excellent fit

• Offer Management Systems — the offer pool, the shopping engine, the fare cache.
• Order Management Systems — system-of-record JSON orders with rich nested structure.
• Reference catalogues — fare families, ancillary catalogues, airport master data, tax rules.
• Audit logs and event stores where ordering and durability matter.
• Embedded scenarios — desktop apps, edge devices, on-prem appliances.
• Anywhere you'd reach for SQLite or a single-node MongoDB today.

Already partially shipped

• Atomic bulk inserts are live today. POST /collections/{name}/bulk?atomic=true turns a batch into all-or-nothing — any failure rolls back the whole batch and the response tells you exactly which document tripped it. That's the primitive most multi-document “transactions” in OMS workloads actually need: amend an order, re-price its services, write an audit row — all together or not at all.

On the roadmap (closer than you'd think)

• Explicit multi-statement transactions. The WAL, CRC32 per record, and crash-recovery primitives are already there — the durability story is solid, and ?atomic=true bulk has proven the rollback path. Adding BEGIN/COMMIT/ROLLBACK across arbitrary statements with serializable isolation is a small, well-scoped extension. Concurrent-reader MVCC is a larger lift, but neither is a re-architecture.
• Multi-master / conflict-tolerant replication. Today's logical replication is single-leader with monotonic sequence numbers — clean and predictable. Document-level last-writer-wins multi-master is straightforward. Per-field CRDT semantics over arbitrary JSON is harder, but the pieces (sequence numbers, replication topology, document versioning) are already in the engine.
• Vector search for embeddings. Brute-force cosine similarity over a small corpus works today via SQL; a real ANN index (HNSW or IVF) is on the roadmap once a use case lands.

→ Full roadmap — engine + admin UI backlog

Probably not our lane

• Petabyte-scale analytics warehouses (use a column store like ClickHouse or DuckDB).
• Full-text search at scale with relevance ranking (use Elastic or Meilisearch).
• Hard real-time transactional banking with formal regulatory audit (use the database your auditor already trusts).

DocumentForge vs. the field

An OMS-grade JSON store has options today: MongoDB Atlas, AWS DynamoDB, Azure Cosmos DB, or relational PostgreSQL with JSONB. Each works. The question is what you give up — and what you pay — to get there. Here's how DocumentForge stacks up on the dimensions that matter for airline retailing workloads.

Indicative annual cost — enterprise OMS scale

Workload assumptions: 1 billion JSON documents (~500 bytes each), ~1 TB on disk including indexes, 100 K reads/sec peak, 20 K writes/sec peak, single region with multi-AZ HA, plus a read-replica or two for follower-scaled reads — i.e. an airline accumulating five-to-seven years of orders, offers, and audit. Prices below are list, single-region; ranges include both on-demand and 1-year reserved/committed pricing.

* Indicative US-region list prices, Q2 2026, sourced from each vendor's public pricing calculator. Ranges span no-discount on-demand at the high end and 1-year reserved/committed pricing at the low end. Excludes data egress, premium support tiers, and add-ons (backup retention beyond default, advanced security, multi-region writes). Use these as a directional comparison for budgeting — not a quote for procurement.

Smaller workload? The gap stays.

Even at a tenth the scale (100 M docs, ~150 GB, 50 K reads/sec) the same pattern holds: DocumentForge runs on $1–3 K/year of commodity hardware, DynamoDB still runs $50–115 K/year provisioned, Cosmos DB $24–35 K, Atlas $12–15 K, Postgres RDS ~$10 K. The advantage isn't that we cut corners at scale — it's that we don't charge you per request, ever.

Why DocumentForge ends up an order of magnitude cheaper

• No per-request meter. Cloud-native databases price the hot path — every read, every write, every retry. At OMS QPS that compounds. DocumentForge runs on hardware whose monthly cost doesn't change whether you do 10 queries or 10 billion.
• You pick the hardware. Hyperscaler instances are quoted at list; commodity hosts at Hetzner, OVH, or your own DC are 3–10× cheaper for equivalent CPU/RAM/NVMe. DocumentForge runs on whatever you point the binary at.
• Single binary, no service mesh. No managed-control-plane fee. No multi-AZ surcharge. No per-collection cost. The replication and sharding logic is in the binary you already paid for.
• Honest licence. MIT means no per-CPU bill, no audit risk, no “can our customer self-host this” conversations with legal.
• Operational truth-in-advertising. Managed services include operations you'd otherwise hire for — backups, failover, monitoring. Factor a part-time SRE into the DocumentForge column if you don't already have one. Even with a full FTE, the gap to DynamoDB at OMS scale is enormous.

Next step

The fastest way to evaluate DocumentForge is to run it. Five minutes, a laptop, and the included benchmark will tell you more than any datasheet.

Quickstart — download the binary, seed 10K orders, run the benchmark →