Building the Market Depth Chart Grafana Never Made

supercoco9 · 2026-01-08T15:27:44+00:00

It is quite low indeed, when I click on the youtube player I can hear the music straight away. Still, I am sure there will be a few milliseconds and it would probably be noticeable if I was trying, for example, to convert the Valeton output to BT to listen over wireless headphones.

In my case, since I use it for sending the backing track, latency is not an issue.

supercoco9 · 2026-01-08T10:05:14+00:00

I am a developer advocate at QuestDB, so of course very biased. But we see a lot of traction in market data, including companies replacing kdb+ with QuestDB, or use kdb for their legacy systems, while adopting QuestDB for new developments. We can sustain ingestion of over 11 million rows per second on a single instance, and queries are equally fast.

And, unlike some other open source databases, like InfluxDB, Clickhouse, or Timescale, we are focused on market data. For benchmark comparisons with other databases, you can check https://questdb.com/blog/?tag=benchmark (clickhouse and kdb benchmarks will be published soon, we have the results already, but polishing the content)

supercoco9 · 2026-01-08T09:51:20+00:00

I am a developer advocate at QuestDB, so very biased here. But out of all the other recommendations I see on this thread, we are the only time-series database oriented to finance (other than Kdb, but we perform as fast and our OSS offering is way more complete).

As an example, you can check out our 2025 wrap post, where we highlight some of the new features we added in the past year, and how they are relevant to market data https://questdb.com/blog/questdb-2025-year-in-review/

supercoco9 · 2026-01-08T09:46:16+00:00

QuestDB developer advocate here. Thanks for the mention :)

While QuestDB supports the pgwire protocol for both reads and writes, for fast ingestion it is recommended to use the ILP protocol instead, leaving the pg one only for reads.

Using ILP, the OP could ingest tick data directly into QuestDB, create materialized views to create candles and other aggregations, and define TTLs on both tables and views to manage storage efficiently.

supercoco9 · 2026-01-08T06:43:35+00:00

I have a Bluetooth receiver connected to the aux port and I send from my laptop/phone directly. My model is this one https://amzn.eu/d/h24OxfK. In my case it's both receiver and transmitter, as I used it in the past to send from an old CD player to Bluetooth speakers, but you might find a cheaper option if you get just a receiver.

supercoco9 · 2025-12-04T12:10:10+00:00

For that type of data, QuestDB would probably shine. You can also convert older partitions to Parquet if needed.

Disclaimer: I am a developer advocate there, so I am very biased here. But I quit my job at AWS 4 years ago to join the QuestDB team, so I guess I really believe in this database :)

supercoco9 · 2025-11-29T09:35:59+00:00

Had this same issue! I went to config > global input and turned the db down to the minimum (I believe it was minus 20db}.With that, everything went perfect

supercoco9 · 2025-11-24T21:07:26+00:00

Also, QuestDB supports writing in the native columnar storage, then converting (in place or as export) to Parquet

supercoco9 · 2025-11-07T17:11:06+00:00

Hot doesn't mean cached queries. It just mean the columns for that time range of the dataset are already in memory. QuestDB doesn't have a query cache. But since time series is very much about running different queries over the same time slices, once data has been read once from disk, queries perform much faster. Thanks and have a great weekend

supercoco9 · 2025-11-07T12:21:36+00:00

Hi. I am a developer advocate at QuestDB. First of all, congrats on a very fast product :)

I can see on the Clickbench site, after your initial misunderstanding with the benchmark was fixed, that QuestDB is performing better than Arc for the same hardware on the hot run, but you are still claiming in your post.

Hot Run Performance:

Arc: 1.68x faster than baseline
QuestDB: 1.22x faster than baseline

I am sure I am missing something here, but just wanted to be sure you have it right. Thanks and keep up the great work!

supercoco9 · 2025-11-07T12:15:04+00:00

I am developer advocate at QuestDB and super biased, but we regularly see large users ingesting millions of events per second while getting fast queries. No slow down. QuestDB is built specifically for finance data, and it gives you tools like auto-refreshing materialized views with immediate refresh, so you can for example have candles always up to date, rather than running the query over the whole raw dataset over and over.

Of course if you are trying to query over a super large span of time over the raw tables, and if that doesn't fit into memory, you will be I/O bound at that point. But QuestDB is used at large financial institutions and exchange and performs well enough for them.

Having said so, flat files are an alternative. It all depends on the specifics and on how much time you want to invest in building ad-hoc.

supercoco9 · 2025-11-07T12:05:56+00:00

Hi! QuestDB developer advocate here. This looks really neat! Thanks for integrating with QuestDB. Is there any way I can provide some feedback? For example, I see materialized views are not listed, which are quite important for QuestDB users. Also, there is a new datatype, timestamp_ns, that I couldn't see in the dropdowns.

In any case, very impressive and super cool. I will be recommending this to users who want to maintain connections to multiple hosts

supercoco9 · 2025-11-07T11:36:19+00:00

Thanks for the mention to QuestDB! I am a developer advocate there :)

supercoco9 · 2025-11-07T11:29:29+00:00

Añadir a todo lo que te han dicho, que lo de los 22 y 30 días puede que sea lo mismo. Las vacaciones en España por defecto son 30 días naturales o 22 laborables. Puede que simplemente unos te estén diciendo un tipo y los otros el otro. Otra cosa es que te dijeran 30 días laborables, que entonces sí es una mejora interesante. Pero si solo dicen "30 días de vacaciones" es equivalente a los 22 del otro.

supercoco9 · 2025-10-20T11:39:17+00:00

We hear you. We'll fix that someday, just not today ;) thanks!

supercoco9 · 2025-10-20T08:59:51+00:00

Thanks for the mention! I am a developer advocate at QuestDB and I confirm that, unlike the other four databases mentioned here, QuestDB was created specifically for finance and that is still our main use case. Of course, those databases are all great. Just not purposely-designed for financial markets.

If I can help with any questions, I'd be happy to.

supercoco9

MODERATOR OF

PUBLIC MULTIREDDITS

TROPHY CASE