* Tiger Shark * Tiger Beetle * Tiger Data * Tiger Games * Tiger Woods * Tiger Attack * Tiger Snake * Wild Tiger
Only one stands out as not like the others. Tiger is too strong a word. The second word disappears.
Also TigerBeetle is an insect, not a fast cat.
Fair. But a mascot is not a name. I hope you can see why I bring this up?
> Also TigerBeetle is an insect, not a fast cat.
It is? Damn. I thought a Tiger Beetle was a six foot long cat wearing costume wings and a springs for antennae?
Is influxdb really seen as a dead end?
While 3. looks impressive, it seems like most of the interesting features are closed source, so not a 1:1 replacement for version 1.
InfluxDB Edge is open-source, but you need to depend on InfluxDB Community which is free, but closed source, to get things like include functionality like a compactor, which will add capabilities for deletes and re-organizing files to optimize for queries on longer time ranges.
They also need to resurrect all their old 1.* Client libraries for 3.*.
I love InfluxDB, but I’m not hopeful for its future.
The 2.x to 3.x move is, admittedly, much harder. This is because of the language Flux. We haven't been able to bring that over to 3.x in a way that makes it useful. We actually built a bridge for it in our cloud offering, but our experience is that the performance isn't good enough to be acceptable for customers wanting to upgrade. If they want to make the move, adopting SQL or InfluxQL is likely the only path.
We'll continue to develop 3.x and we'll build more migration tooling over time. I think we can build specialized tooling to help Flux users migrate over to 3.x with query translation tools, but there are more features we need to land in 3.x to enable that first.
We're committed to the technology stack (Apache Arrow & DataFusion) and the 3.x line. We have no plans for another major release. I'll be happy if we end up releasing 3.56.2 8 years from now.
I did some work using pgvectorscale and their hosted offering a few months back and the product and the team were a delight to work with. I wish TigerData well.
Not for AI or other bs "pivots"
I guess it’s just another columnar dbms after all?
In a way Timescale is just postgres on steroids. Sure if you really know your use-case well, are fine with giving up some postgres nicenes, are willing to learn a new query language and are fine with using and syncing multiple data stores you'll outperform timescale. But I think it is still really cool to see how close you can get with essentially just a better postgres.
Is this relevant? The benchmark is just reads.
You might still be better of with Timescale/TigerData if your query pattern uses a lot of joins as we do much better there than Clickhouse does. We have our own benchmark too and perform better than Clickhouse on those kind of queries: https://rtabench.com/
But also transactions often make your life as a dev easier in my experience, and being able to use a single DB and stick with 100% postgres compatible SQL without having to change your application is often worth more than squeezing out the last few bit of query performance.
I'm just saying that single-benchmark comparisons rarely tell the full story when evaluating database technologies. ClickHouse is undoubtedly impressive engineering, and it excels in many scenarios. Ultimately the optimal choice depends on your specific use case.
I agree with the other points. ClickHouse is not strong on joins [yet]. It's also nice to have a single database for everything. Yet so far nobody has been able to achieve one that delivers high concurrency, fast updates, and petabyte-level scaling. Mike Stonebraker et al. called this problem out in 2007. [0] It appears they called it right and we'll continue to see 2-3 major categories of databases for the foreseeable future.
[0] https://www.vldb.org/conf/2007/papers/industrial/p1150-stone...
"ClickBench evaluates databases using a single table of clickstream data, representative of workloads like web analytics, BI, and log aggregation. It also favors full-table large scans and large-scale aggregations on denormalized data.
Real-time analytics inside applications is different and needs a new benchmark." [0]
This is why we published RTABench. [1]
We believe that it is more representative of real-time analytical workloads.
[0] https://www.tigerdata.com/blog/benchmarking-databases-for-re...
> The majority of workloads on our Cloud product aren’t time-series. Companies are running entire applications on us... So we are now “TigerData.” We offer the fastest PostgreSQL. ... Our cloud offering is “Tiger Cloud.” Our logo stays the same: the tiger, looking forward, focused and fast... Our open source time-series PostgreSQL extension remains TimescaleDB. Our vector extension is still pgvectorscale. Why “Tiger”? The tiger has been our mascot since 2017, symbolizing the speed, power, and precision we strive for in our database.
Given the logo (and internal company culture around the tiger mascot), I understand where they're coming from, but with the name conflicts (TigerBeetle, WiredTiger, etc) I do wish they'd chosen something else -- like maybe TiScaleDB and give a titanium sheen, do triple duty with the tiger and the Timescale heritage?
I'm pretty sure Tigris Data is named after the Tigris river (https://en.wikipedia.org/wiki/Tigris), and the name does not mean "tiger".
The common underlying etymology is an even older into-european term translated roughly as "sharp" or "pointy" (in the case of the tiger I guess referring to the teeth).
From a biblical etymology page:
The name Tigris shares its root with the word "tiger" (more precise: the word "tiger" and the name Tigris are identical in Greek). That means that in deep antiquity the tiger and the Tigris had signature qualities that were comparable and from which both derived their name. The word tiger and the identical name Tigris both come from the Avestan word tighri, which means arrow, or the more general tigra, which means sharp or pointed.
In 2017? I thought the NoSQL hype had subsided by then and everyone was excited about distributed transactions -- Spanner, Cockroach, Fauna, Foundation, etc.
"The future is already here, it's just not very evenly distributed" - William Gibson
That's quite some statement. Boy, would I have loved to live in a world where marketing rhetoric and scientific opinion were easier to distinguish.
There's an element of immaturity in the style that they should probably work on.
One annoying thing is that tiered storage is not available on their Azure offering, and also in general it feels like managed service for TimescaleDB is the unloved stepchild of their offering.
But yes, I hope the team continues their amazing work, and I'm looking forward to seeing how the project develops in the future.
TigerData is bold, fast, and built to power the next era of software.
Care to elaborate on why you posted this?
Did you try Slack?
Cringe...!!!
1: https://media.karousell.com/media/photos/products/2018/11/10...
I know it's popular to bash the HackerNews hivemind, and often it's honestly deserved, but this line is in bad taste. The comment was not only polite and professional, it was also right. They had to introduce a columnar storage format (hypertables) to make it work. That is exactly what the comment and the follow-up cocmment suggest.
Together with the other paragraph with the bashing of the competition this just looks like your company starts to develop an echo chamber where you’re internally so fine with speaking like that, that it leaks out to the public. For comparison, at my company we don’t even speak about our competition like that internally. Let your readers come to the conclusion that you’re better than the competition by showing the necessary facts only.
Query optimization is one of those places where it can be easy to get orders of magnitude performance increases.
It’s my fervent belief that we should revert to specialized roles, with a DB team designing schema and queries based on a team’s needs, who can access them via API only. Slows down velocity? Yes. Faster queries and more efficient use of resources? Yes. Fewer incidents and better referential integrity? Also yes.
I recommend it when you don't want/need to have separate sources for account data and your metrics/aggregate data.
https://chatgpt.com/share/6852de93-1384-8004-ac63-4ae93a8373...
It is just my guess.
justinmitchel•7mo ago
Cool!