I've worked on query engines, storage engines, incremental view maintenance, streaming queries, declarative languages, end-user programming tools, IDEs, interpreters and compilers, and general performance engineering.
I'm happiest being aimed in the general direction of a hard problem and trusted to figure it out.
I'm based in Vancouver BC. I'm not interested in relocating but I'm happy to travel. I have Canadian and British citizenship.
employment
TigerBeetle 2022-2023. High-performance database for financial transactions, able to detect and recover from most hardware failures.
I was the main person working on storage engine performance and correctness. When I joined we were averaging 2,734 transfers/second with a peak (closed loop) latency of 14,749ms. Within three months we had it up to 120,397 transfers/second with a peak latency of 3,817ms. I also identified many bottlenecks that led to later performance improvements, and fixed some gnarly bugs (eg #390 which combined a race, a use-after-free, a partial hash collision, and a zig compiler bug).
Jamie is a lion you let loose on some of the toughest technical problems in your code base. Jamie is fiercely independent and will deliver on skunkworks projects. He cares deeply. You can trust Jamie to do it right, and see it through.
Joran Dirk Greef, CEO
Materialize 2019-2020. Incrementally maintained sql views over streaming data. Fully postgres-compatible.
I wrote much of the sql frontend and ported >6m tests from sqlite/postgres/cockroachdb. I also wrote the decorrelation pass, which I believe at the time was the best in the world (hyper was comparable, but had some nasty edge cases that I accidentally avoided), and switched the internal storage from naive vec-of-enum-of-strings to a packed encoding with a single allocation per row.
Fun fact: I was hired on a three month trial contract because Materialize were reluctant to have a remote employee. The trial was converted to full-time on my third day after I landed support for union, distinct, aggregates, and also found and fixed a bug that silently dropped duplicate rows.
Jamie was fundamental to building the foundation of Materialize. Not only was he a phenomenally productive engineer, he was able to synthesize lots of academic research to solve complex problems from first principles.
Arjun Narayan, CEO
Eve 2013-2016. A sane end-user programming environment.
We built a declarative language with incremental evaluation, a live notebook interface, a gui library, an inspector and a debugger. The team started with just two engineers so I touched everything.
Jamie brought a degree of rigor and theoretical knowledge that took the company to places we never could have gone otherwise. From exploring the implications of language semantics to building high performance database engines, he didn't just help us get things done, he helped us get them done right. As a result, we were able to explore in weeks what could've easily taken years.
Chris Granger, CEO
consulting
Runway 2025. Timeseries spreadsheet for financial planning.
I was brought in to help with the performance of their timeseries interpreter as they were scaling up to bigger customers. I reduced the p50 recalculation time by 4x and killed several superlinear edge cases that were plaguing specific customers. I also helped set up continuous benchmarking infrastructure and expanded their existing continuous profiling to be able to break costs down by customer and function, to ensure that they were able to catch future regressions.
Gel 2025. Database with a query language for returning hierarchical data.
I wrote a detailed review of their query language looking for sharp edges, inconsistencies, opportunities to simplify constructs, pointers to existing solutions in other query languages etc. I also discovered several serious performance bugs.
SuperDB 2024. Query engine for heterogeneous data.
I helped sketch out the architecture for their new vectorized query engine, which was built gradually by opportunistically replacing leaf operators in the query plan with vectorized operators, and falling back to the scalar query engine for the remaining operators. Implementing the basic sargable operators gave them an immediate performance boost by reducing both the amount of data downloaded from the data lake and the amount of data flowing into the scalar query engine, while also leaving the door open to incrementally vectorize the rest of the language later. I added a fuzzer to compare the scalar and vectorized implementations, which also surfaced a number of crashes and infinite loops in the original scalar query engine.
XTDB 2022. Bitemporal database.
I was brought in as an advisor on their sql implementation to steer them clear of common pitfalls, stress-test weird sql edge cases, and point out which research papers actually work and are worth reading.
LogicBlox 2016-2017 / RelationalAI 2017-2019. Declarative programming languages for building complex business models.
Various projects, including:
- Compiling gui programs to the Logiql language, reusing the existing incremental view maintenance to derive precise DOM updates.
- An early prototype for the Rel language with sound denotational semantics for higher-order relations, a simple type analysis that prevents logical contradictions, and staged compilation via piggy-backing on Julia.
- blobs.jl - a library for memory-safe zero-cost zero-copy deserialization.
Jamie is a first principles thinker with a deep understanding of systems and algorithms. He is fearless in the way he approaches problems. Jamie's research on staged compilation saved our team many person years of effort, and his training and support was crucial to our adoption of Julia. I hope to have the opportunity to work with him again soon.
Molham Aref, CEO
projects
In 2022 and 2025 I single-handedly organized an online conference, with a total of 72 talks and 1010 attendees between the two events.
HYTRADBOI was the best bang-for-my-buck (both in time and money) event that I attended last year. This year looks equally great! If you are interested in PL or DB, it's worth it; if you like both it's a must see!
Sidenote: I think it's a great example of how to run an efficient remote conference!
Max Willsey, UC Berkeley
Internal consistency in streaming systems
I demonstrated that popular streaming systems (kafka streams, flink) can produce large, cascading, and chaotic errors even on simple queries, leading to a situation where the vast majority of outputs are not only incorrect but are not even possibly correct for any set of inputs (eg outputting a negative stddev). I also explained the additional consistency requirement that would guarantee that outputs are sane.
Jamie Brandon's (@sc13ts) work on stream processors is like @aphyr's work on databases: empirically testing consistency. Very interesting.
Martin Kleppmann, author of Designing Data-Intensive Applications
Zest.
A WIP language aiming to be both malleable and legible. Sound gradual typing. Borrow-checking without type-checking. Serializable values and types. Hot code reloading with well-defined semantics, and without mutable environments. Staged evaluation.
Imp.
Various experiments in creating a purely relational language. Supports higher-order queries and correlated subqueries, with a type system that ensures that every well-typed program can be lowered to a first-order relational dag. Gradually typed for interacting with unstructured data. Algebraic types and first-class modules fall out of the same type system.
As a challenge, I tried to write a sql query engine from scratch in a week that could pass all 4259065 tests in the public sqlite test suite. I managed 95.26%.