nhourcard
Joined 7 years ago
Karma
82
Submissions
96
Member since
Nov 1
Recent submissions
Comment · 3 months ago
TSBS (Time Series Benchmarking Suite) is as close as it gets
Comment · 1 year ago
QuestDB | C++/Rust Database Engineer | REMOTE| | Full-time | https://www.questdb.com
Work with world-class engineers - including two teammates who placed in the top 10 of the One Billion Row Challenge (1BRC).
As a specialized database, QuestDB stores, processes and analyzes time series data in real-time, with a focus on reliability, extreme performance and simplicity. It provides best-in-class hardware efficiency and robust features, saving costs and accelerating time-to-value.
Our open source repository has gathered 16k stars and QuestDB is one of the fastest growing database in the category. We are a product-first company with a large community of developers. As a team, we are globally distributed, remote-first and backed by leading venture capital firms and Y Combinator.
Teams have had success with QuestDB across a wide range of industries, such as Financial Services, Energy and Space Exploration. Category leading companies such as OKX, Mizuho, and Airbus rely on QuestDB for large-scale, data-intensive production systems. Emerging and disruptive startups also leverage QuestDB to gain a significant edge within traditional industries.
To apply: https://questdb.com/careers/core-database-engineer/
Comment · 2 years ago
TLDR from the article;
Alternatives (which are open source) to KDB+ are split into two categories:
New Database Technologies (tick data store & ASOF JOIN): Clickhouse & QuestDB
Local Quant Analysis: Python – with DuckDB & Polars
Some personal thoughts:
Q is very expressive, and impressive performance can be extracted from kdb+, but the drawbacks are proprietary formats, vendor lock-in, costs, proprietary language and reliance on external consultants to make the system run adequately, which can increase operational costs.
I'm personally excited to see the open-source alternative stack emerging. Open Source time-series databases and tools like duckdb/polars for data science are a good combination. Storing everything in open formats like Parquet and leveraging high-performance frameworks like Arrow is probably where things are heading.
Seeing some disruption in this industry specifically is interesting; I think it will be beneficial, particularly for developers.
NB: disclosing that I'm from questdb to put thoughts in perspective
Comment · 2 years ago
QuestDB | Remote | Full-time | questdb.io
QuestDB is one of the fastest-growing time series databases and is growing its engineering team. QuestDB is open source, and the code is available under Apache 2.0 at https://github.com/orgs/questdb/
Our team is obsessed with performance; it is a blend of low latency zero-GC Java, C++ and Rust (for the entire distributed architecture). Check out our blog post for heavily technical content about the project: https://questdb.io/blog/tags/engineering/
VC funded with plenty of runway, investors include YCombinator, and founders of Github, Docker, Supabase, Posthog, NGINX, Mesosphere, Citus Data and more.
Job application here: https://questdb.io/careers/core-database-engineer/
Comment · 2 years ago
Interesting release, it feels that the time-series database landscape is evolving toward:
a) columnar store & built from scratch, with convergence toward open formats such as parquet & arrow: influxdb 3.0, questdb
b) Adding time-series capabilities on top of Postgres: timescale, pg_timeseries
c) platforms focused on observability around the Prometheus ecosystem: grafana, victoria metrics, chronosphere
Comment · 2 years ago
About the market data & monitoring element, beyond the usual suspects Clickhouse and kdb+ - worth noting that Aquis mentioned in this article uses QuestDB ( https://questdb.io/case-study/aquis/)
Comment · 2 years ago
In QuestDB, only SYMBOL columns can be indexed. However, sometimes, queries can run faster without indexes. This is because, under the hood, QuestDB runs very close to the hardware and only lifts relevant time partitions and columns for a given query. Therefore table scans between given timestamps are then very efficient. This can be faster than using indexes when the scan is performed with SIMD and other hardware-friendly optimizations.
When cardinality is very high, indexes make more sense.