Bringing Local Analytics to the Quant's Desktop

2026-11-03 6 min read

Ryan Hamilton

Geertjan Wielenga

Tim Cox

Quote

I like the simplicity of just a small thing running and working. And then you can get more complex.

— Ryan Hamilton, founder, TimeStored

Fifteen Years of Heavyweight Infrastructure

For about fifteen years, Ryan Hamilton has built large market-data platforms for banks and hedge funds. Most of that work was in kdb+, integrated with real-time messaging systems such as Solace. He built much of the platform at UBS and almost all of it at Citi, contributed to Morgan Stanley's, and most recently worked at a hedge fund.

His users are typically teams of 10 to 15 quants. They are deep specialists in finance who spend anywhere from a tenth to more than half their time on technology. Ryan's job has been to store their data efficiently so they can get on with their work. Sometimes he leads a team to do that. Sometimes he builds it himself. Sometimes he talks quants out of building infrastructure on their own.

Problems That Didn't Need a Heavyweight Answer

Alongside that work, startups, smaller tech firms, and smaller funds kept asking Ryan the same question: what should we run this on?

For years he had no good answer. He tried other systems but found that their license was prohibitively expensive, their setup didn't offer an embedded mode of operation, or they were much more operationally involved than he wanted at the time. For some clients, the honest answer was that he would write something in C for their narrow use case.

A Different Starting Point

DuckDB was different. It was small, embedded, reliable, and analytically capable, and a team could start with it inside an application without standing up a server.

“I like the simplicity of just a small thing running and working,” Ryan says. “And then you can get more complex.”

That let him give smaller firms a straight recommendation. DuckDB might not scale to everything, but it would run well and serve them for a long time. For roughly 90% of use cases, he reasoned, it would carry a team for years. By the time they outgrew it, they would understand their workload well enough to choose what came next. In many cases, DuckDB has expanded quickly enough that they never needed to move.

QStudio: A Local Analytical Sandbox

The clearest illustration is QStudio, the analytics IDE Ryan released about 13 years ago. It was originally built for kdb+ and now connects to around 15 databases. He leaves database administration to tools like DBeaver and focuses QStudio on analytics and charting.

DuckDB was the first deep integration, and it changed how quants work with expensive queries. The workflow runs like this. An analyst runs a heavy query against a remote database. Some of these take up to 20 minutes. QStudio then saves the result locally as Parquet through DuckDB, with a click in the UI.

The next day, the analyst queries that saved result directly, without rerunning the original workload:

SELECT
    symbol,
    avg(price) AS avg_price,
    sum(volume) AS total_volume
FROM 'results/trades_2026-11-10.parquet'
GROUP BY ALL
ORDER BY total_volume DESC;

The result is a personal sandbox where quants can build on their own earlier work. It proved popular, and Ryan found its performance close to kdb+'s.

Because QStudio is a Java Swing desktop application deployed inside banks, the integration depends on DuckDB's Java client. Ryan's early version relied on inefficient workarounds to get appending working. Once a dedicated Java developer joined and rebuilt the Appender properly, every kink was ironed out.

“It just worked,” Ryan says, “which is the highest praise I would give any engineering thing.”

That experience became the basis of his DuckCon talk. His argument was that an open-source engine already beat a far more exotic and expensive stack in some areas. DuckDB has moved well ahead since then.

Pulse: DuckDB by Default

QStudio was never a significant direct revenue generator, but it got a very small company onto the approved-vendor lists of some very large firms, which is hard for small vendors to do. When Ryan's company, TimeStored, launched Pulse, a real-time HTML visualization tool that is now its main product, that path into large firms already existed.

Ryan reached for DuckDB again. Pulse uses it to snapshot and cache data. What began as an integration experiment had become a repeated TimeStored architecture pattern. DuckDB sits in the embedded storage and query layer, and increasingly supports AI-assisted data exploration. Excel exports and similar user-facing features stay in the application's UI. That is partly to keep styling intact, and partly because bank users often can't install extensions at all.

PeachQ: Back to Q

Ryan's newest project is PeachQ, an open-source implementation of the Q language. Ryan loves Q as a language but thinks DuckDB is ahead as a database, so PeachQ separates the two.

PeachQ uses the Rayforce in-memory engine and DuckDB-backed historical storage to deliver a modern, open-source alternative to kdb+, bringing together real-time processing, powerful analytics, and efficient storage in a single system. Ryan's recent work on C extensions points the same way, along with experiments with newer formats such as Vortex and custom table formats. He credits DuckDB's extension API with letting people add features cleanly, unlike the fragile workarounds he and others once built into closed systems. Often, he notes, DuckDB later builds those features itself.

Learn More

Ryan's DuckCon talk gives a short tour of this work.

You can explore QStudio, now open source, and try PeachQ at peachq.org.

We would like to thank Ryan for the conversation. You can follow his work on DuckDB, Q, and TimeStored at timestored.com. And if you are reading this, are using DuckDB, and would like to share your story, drop us a line at [email protected].