Compile, don't interpret

Five stages, all at build time

Nothing on this path runs on the player's device. The output is plain C# (or a portable artifact) — there is no query parser on the hot path.

A glass box, not a black box

A Cascades-style, cost-based optimizer makes the choices a senior engineer makes by hand — which index, which join strategy, what order, when to stop scanning, whether to eliminate a sort — but deterministically and exhaustively, using your schema, your indexes, cardinality estimates and profile data. The difference: every choice is inspectable. The plan is output you can read; the strategy names are real and finite; nothing is hidden.

# the plan ConjureDB picks for GetTopScorers — inspectable
 
TopN (limit=count, order=score desc)
└── Scan (Player,
         strategy=SortedSetScan,
         index=Player_ByScore)

Keep the result. Apply only the change.

Static queries are the easy half. Your shop screen isn't static — it changes whenever anything it depends on changes. Incremental view maintenance keeps a materialized result fresh by applying only the delta: add an item, you add one row; change a config field, you touch the rows that pointed at it. The cost of staying fresh scales with the size of the change, not the size of the data — the only property that fits inside a frame.

And it is honest about its limits: a query shape it cannot maintain incrementally is rejected at compile time, never silently degraded to a hidden full rescan.

If you don't trust it, read it

The generated code is plain source you can open. There is no reflection, no runtime code generation, nothing dynamic on the query path — which is exactly why it survives IL2CPP and a tight mobile frame. ConjureDB earns trust by removing mystery, not by asserting quality.