If you just want to compare the database aspects that works. Once you get into other features that gets messier as functionality is split across components in different ways.
For example Prometheus vs InfluxDB is not a great comparison, whereas Prometheus+Alertmanager vs InfluxDB+Kapacitor is.
True, but note that the comparison only focuses on SQL (as it related to PostgreSQL) features and not any DB-specific features.
The YugaByte DB specific pieces are not included as well - for example, support for YCQL (Cassandra-compatible) and YEDIS (Redis-compatible) APIs to the DB.
Does anyone know a comparison between this and CockroachDB? Or have experience running either in production?
They seem to compare against other databases, but not against Cockroach which seems to be the biggest competitor. I'm looking at implementing a global-scale database cluster with very specific requirements, and YugaByte seems to meet those but a comparison against CockroachDB seems warranted.
It's comparable based off of the fundamentals and I have the same question.
They both use KVs using LSMs, do range queries, support ACID transactions, handle resharding and clustering for you.
They're both based off of Spanner fundamentals. They both actually have an SQL layer - foundationdb's is the record layer. Just because one has a primary SQL interface doesn't mean we can't compare.
I'd really like to know a comparison of the fundamentals including hotspot management, resharding, read/write performance, resharding etc. also and have been looking for this.
What are your requirements? We see some people switching from InfluxDB to QuestDB. Common reasons include SQL support (InfluxDB strategy is a bit confusing here), performance and issues with high-cardinality in InfluxDB.
Full Disclosure: I work for QuestDB and I am obviously biased.
Yes, it looks really good — but it's a different kind of database (I think). From a quick glance, it's an embedded object database used mostly client-side, while what I need is a distributed server-side database.
Since it doesn't support serializable transactions I'm not sure why FoundationDB would be mentioned as a comparison in the write up. The operations it does support seem to set the bar pretty low as to what to test.
edit: good reply by the founder of YugaByte but for some reason the comment is dead. I have noticed that when founders don't have an account on here and then something comes up where they need to reply their comments are often deaded.
Disclaimers: I was CTO@Kx for a while, but also like InfluxDB :-)
It is definitely more finance oriented, though Kx are making moves towards other application areas. Another difference I'd highlight is that Kx concentrate on the core database itself, esp. performance and expressiveness of the query language, and leave things like GUIs and admin add-on tools to partners (like first derivatives and aquaq).
kdb does just fine with metrics and sensor data. Personally, I would argue that it's weaker on string handling though, which can hurt in certain use cases.
I doubt it'll go open source any time soon. However, it being around a long time is something salescritters can spin to wonderful effect re stability, support, etc etc. ;-)
I think there are fine application areas in finance that you should consider -- just consider the many areas where the core problem isn't related to juggling TB of market data ticks coming off the exchanges.
The differences in 2.x and 3.x are quite significant. The 3.0 database was a ground up rewrite in a new language (v1 and v2 were in Go, v3 is in Rust).
InfluxDB v2 was all about the Flux language and a much broader set of API capabilities along with an integrated UI.
For 3.0 we focused on the core database technology. We were able to bring the 1.x APIs forward, which means 3.0 supports both InfluxQL and SQL natively. We were only able to add Flux support through a separate process and a lower level gRPC API that the two use to communicate.
The underlying database architecture is also completely different. v1 and v2 are essentially an inverted index paired with a time series store. v3 organizes data into larger Parquet files and pairs that with a columnar query engine (Apache DataFusion) to execute fast queries against it.
Me or someone on our team should probably write a detailed post about the underlying database architecture to highlight the differences between the versions.
We built 3.0 mainly to accomplish some things that we were unable to deliver in v1 or v2:
* Unlimited cardinality
* Tiered data storage
* Fast analytic queries
* SQL compatability
* Bulk data import and export (coming soon to v3)
Then there are the systems architecture changes we made highlighted in this blog post. v1 InfluxDB was a monolithic database that had all these components in one. The v3 design allows us to scale ingest, query, and compaction separately, which is something that kept coming up in larger scale use cases.
For example Prometheus vs InfluxDB is not a great comparison, whereas Prometheus+Alertmanager vs InfluxDB+Kapacitor is.
https://prometheus.io/docs/introduction/comparison/ has such a comparison, though it's a few months out of date.
[Disclaimer: Prometheus developer]
reply