Performance and speedup

Faster, and proved the same.

API gateways and database queries. The result this engagement is for is a 2x to 10x latency reduction. A theorem prover checks that the faster program executes identically to the original.

Same rows, same values, same errors.

Tell us about the workload

The specification stays fixed

A faster program is accepted only when it still meets the contract. For a query, that means the same rows, the same values and the same errors as your engine. For a gateway, it means the same decision for every valid request.

We specialise the execution: code built for this one statement or these routing rules, not a hint the optimiser may ignore. With the code comes a proof, and a check that the code we proved is the object you deploy. Its contents are identified by digest. If the two differ, it does not run.

Where the time goes

01

API gateways and proxies

A specialised C or Rust binary for your routing rules, proved to match the contract for every valid request.

02

Database queries

The optimiser still picks the plan. We compile the execution of that plan for this statement and your schema, and prove it returns the same rows, the same values and the same errors.

03

Spatial queries

Tracking, telemetry and geofencing run the same prepared statement millions of times a day. A point-in-box check often spends more CPU on engine overhead than on the coordinate maths. On simple range-scan benchmarks, the compiled replacement reached 1.95×.

Which workloads pay

A strong fit

  • A fixed, simple plan run millions of times, such as a scan with a range filter, or a bounding-box check. The plan is settled before the first row is read.
  • An API gateway or proxy whose routing rules are stable, and whose cost is execution rather than waiting on a third party.
  • Small, uniform work per row or per request, where the cost is dispatch and decoding rather than the volume of data.
  • A long-lived prepared statement, so the specialisation is paid for once and spread over its whole life.
  • C, Rust or C++ services where you can give us the source, the build, and the benchmark.

Not a fit

  • Plans whose shape changes between runs
  • Scans where reading the data dominates the per-row work
  • One-off analytical queries
  • Anything a general optimiser rewrite already captures
  • Bottlenecks that are third-party network wait, rather than your own code

What we have measured

One machine, one query shape: SELECT x FROM t WHERE x >= ?1, 100,000 rows, answered in 3.7 to 4.2 ms. Every variant was measured side by side in the same run, relative to that build's own baseline. The 2x to 10x figure is the result the engagement is for. These ratios are what that query returned.

Relative speed of query replacement variants on one range-filter plan
Variant Relative speed
Engine as shipped 1.00×
Specialised region, AI hand-written 1.35×
Plus the specified consuming boundary 1.81 to 1.82×
Plus storage-layer changes 1.95 to 1.96×
Widened variant, on a two-column plan 1.77 to 1.82×
  • These ratios are for this query shape, this build and this machine. Per-row dispatch and decoding is what we expect to generalise. The exact ratios are not a promise for another workload.
  • 1.95× includes storage-layer edits. The variant under certification specialises the query, the row read and row construction. The same class of range-scan is where the spatial benchmarks reached 1.95×.
  • The speed-up is quoted against the same build's baseline in the same session, because absolute times move between sessions.

How an engagement works

  1. Specify

    The contract states what the gateway or the query must do: the same routes, the same rows, the same values and the same errors.

  2. Compile

    We replace the generic path with code built for this plan, this schema, or these routing rules.

  3. Prove

    A theorem prover checks that the faster program executes identically to the original for every valid input. A digest binds the proof to the object you deploy. If the two differ, it does not run.

  4. Measure

    The faster program is benchmarked against the same build, in the same session. You receive the measurement with its controls.

For a C, Rust or C++ service, the commercial term is separate from the measurement above. You pay a fee only if we improve service speed. Otherwise you owe €0. Source access is covered by an NDA. That term is for this engagement, not a promise that every workload reaches 2x to 10x.

Tell us about the workload

Send the gateway, the statement, or the spatial query, and how often it runs. We will tell you whether this replacement is a fit.

Send us a message

Step 1 of 3