Why S-Expressions - MODOLAP
MODOLAP
SubscribeSign in
Why S-Expressions<br>In Finance, In Technology, And in Life, Every detail matters.<br>Jul 21, 2026
Share
When implementing a new data system, The question of what query language would be exposed to the user is prevalent. In most cases, it ends up being SQL. In some cases, it starts with a “SQL Replacement” and slowly, or quickly, becomes SQL. When commercial relational databases had their first innings, There existed Larry Ellison’s Oracle and Berkeley’s INGRESS. OracleDB supported SQL from the start, INGRESS used QUEL, some academics may to this day argue QUEL is, in some sense, superior, yet the ship has long sailed. OracleDB dominated. as the story goes, when a standards committee hosted a symposium on whether to choose SQL or QUEL, LE came and MS didn’t [1]. This is a lesson in business as much as database technology. (INGRESS later spun out as PostgresSQL)
Thanks for reading MODOLAP! Subscribe for free to receive new posts and support my work.
Subscribe
MDBX is a financial data processing system, it’s built from the ground-up for real time, Low Latency High Bandwidth financial workloads and is one of a kind. While initially planning on supporting the standard of SQL, I have directed towards a different solution, an IR which is proprietary. While for most DB systems this is a subpar choice in terms of adoption, I would argue for MDBX it makes sense.
The Finance world has always given birth to terrific technologies. The finance world is great. A financial data processing system which supports arbitrary queries is utterly orthogonal to a relational database. Thinking from first principles, A Firm would like a system which can ingest millions of market data updates from prop feeds in real time, continuously, throughout the trading day, The system shall both store the market data and perform user-defined quasi-mathematical transformations upon it. Preferably, throughput of query updates shall ~linearly scale with inserts, with constant, minimal latency. Factor in User Experience, This is a very hard unsolved problem.
The fact queries would come in the form of mathematical transformations, and that they are read-only, bears the opportunity to build anew and depart from legacy constraints. MDBX, as of writing, implements a Reduced Instruction Set, In some sense similar to tinygrad [2] just instead of targeting Machine Learning, it targets Financial Workloads. Yet forcing a user to express queries in said reduced instruction set would, in some cases, degrade user experience, And therefore is a route not pursued. Instead, I implemented UOPSX, an S-expr, lisp-derived frontend language which can be easily formatted, linted, optimized and lowered to a sequential UOp program. S-Exprs, in their nature, are in some sense a partial equilibrium between Human-Targeted languages and Machine-Handleable intermediate representations. An RTQUERY expressed as an S-expr transforms nicely to the underlying, proprietary and optimized MDBX Intermediate Representation.
In the recent, first, Black Scholes workload [3], the UOPSX program was:<br>(program<br>(output stream)<br>(backend rt)<br>(scan {options} :as options)<br>(scan {quotes} :as quotes)<br>(asof-join options quotes :as joined<br>(on t t) (by ticker ticker) (prefix quote_))<br>(project joined :as book<br>(field contract contract)<br>(field ticker ticker)<br>(field quote_t quote_t)<br>(field sent_ns quote_sent_ns)<br>(field sequence quote_sequence)<br>(field spot (/ (+ quote_bid quote_ask) 2.0))<br>(field theoretical<br>(black_scholes_price<br>(/ (+ quote_bid quote_ask) 2.0)<br>strike years volatility rate is_call)))<br>(root book))
For a competent quant this is straightforward.
The MDBX Client SDK, especially the python one, supports and would improve support for Fluid-esque Builder APIs, meaning that individuals already familiar and comfortable with vectorized numerical libraries such as OpenBLAS and Numpy, or ML frameworks such as torch or TVM (the latter is underrated! especially for inference) can port their transformation with minimal, to virtually non-existent, overhead.
In essence; For most new data systems, it makes the most sense, both business and technology wise, to support ASCII SQL as a first-class query language. MDBX, a system built from first principles for financial and tick data workloads, seeks to deliver the pareto-frontier performance to its customers, with the best interfaces. Due to the mathematical nature of most queries, I decided upon not borrowing Legacy Debt (regardless of the interest :)) and have a custom query language with Quant-Aligned SDKs which are being continuously improved. In the future, if it aids our customers, it may make sense to implement an auxiliary S.Q.L frontend, yet for now, it makes sense to focus on having the most performant, robust, and nice-to-use system.
Empower Your Financial Workloads
MDBX is available today, supporting both managed, BYOC, and on-prem installations. It can replace either generic systems not...