> There are no more “SQL vs. NoSQL” debates. MongoDB, Cassandra, InfluxDB, and other NoSQL databases are seen as technical dead ends. Snowflake and Databricks are acquiring PostgreSQL companies. No one talks about Hadoop. The Lakehouse has won.
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.
sgarland 11 days ago [-]
Cassandra definitely isn’t dead, anyway. InfluxDB is a competitor to Timescale / TigerData, so that’s just a slam on them. I don’t think about MongoDB, other than of course the canonical video [0].
Also linking to an old HN comment to gloat about how wrong the doubters were is not a good look.
There's an element of immaturity in the style that they should probably work on.
inamorty 11 days ago [-]
I concur, the tone is very off-putting.
baggiponte 11 days ago [-]
Yeah they might be good but the marketing is really bold and, to a certain extent, arrogant if not outright disgusting.
suyash 11 days ago [-]
It sounds totally illogical comment, all those technologies mentioned have only been growing in the last few years and specialised databases are disrupting old school SQL ones.
victorbjorklund 11 days ago [-]
In a way I guess this makes sense because they are not just doing time series anymore but on the other hand that is just a very strange name. I'm just thinking about Tiger Beetle and I'm sure they will lose so much in brand awareness because people have heard about timescale db but they have not heard about tiger data and the name just sounds so cheesy.
ethagnawl 11 days ago [-]
This makes a certain amount of sense because it seems like the actual timescale DB extension/support/etc. they offer is becoming exponentially less important to their company as a result of their pgvectorscale offering. (I'm sure the post says as much.)
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.
apgwoz 11 days ago [-]
So there’s TigerData and TigerBeetle. I wish they would have chosen a different fast cat…
WildcatDB, though uses a cheetah for the logo RocksDB uses an I believe tiger for the logo as well. Postgres with the elephant, MariaDB with the seal.
evanelias 11 days ago [-]
Small corrections: RocksDB's logo is a cheetah. MariaDB's is a sea lion, which is similar to a seal, but is delightfully relevant to this thread due to sounding more cat-like.
Too bad they weren’t French, or a new breed of Riot Grrl databases. Le Tigre DB rolls off the tongue.
evanelias 11 days ago [-]
Finally, a database that we can query to determine who took the bomp from the bompalompalomp?
apgwoz 10 days ago [-]
As long as the DB doesn’t show its disco, I think we’ll be OK even without an answer.
akulkarni 11 days ago [-]
We chose the Tiger back in April 2017.
Also TigerBeetle is an insect, not a fast cat.
apgwoz 11 days ago [-]
> We chose the Tiger back in April 2017.
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?
tao_oat 11 days ago [-]
And TigerGraph, too!
11 days ago [-]
jabiko 11 days ago [-]
We've been using TimescaleDB/TigerData for over five years now and it has proven to be a reliable component of our project. We process and store hundreds of data points for a six-digit number of industrial robots and TimescaleDB is what makes that possible. While I can't speak for Timescale Cloud, the managed service for TimescaleDB on Azure has been rock solid.
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.
ramonguiu 11 days ago [-]
@jabiko thanks for the note. Glad our product is working so well for you.
re:Azure we are working on some new things :) . Feel free to drop me a message if you'd like to discuss further (ramon@tigerdata.com).
cakoose 11 days ago [-]
> When we started 8 years ago, SQL databases were “old fashioned.” NoSQL was the future. Hadoop, MongoDB, Cassandra, InfluxDB – these were the new, exciting NoSQL databases. PostgreSQL was old and boring.
In 2017? I thought the NoSQL hype had subsided by then and everyone was excited about distributed transactions -- Spanner, Cockroach, Fauna, Foundation, etc.
politelemon 11 days ago [-]
I think this just illustrates the tech bubble we live in. Occasionally we find one that doesn't match ours.
akulkarni 11 days ago [-]
Exactly!
"The future is already here, it's just not very evenly distributed" - William Gibson
dgellow 11 days ago [-]
I had the same thought. They are off by a few years
spooneybarger 11 days ago [-]
Marketing is going to market.
conradev 11 days ago [-]
TigerData is bold, fast, and built to power the next era of software.
When I saw the headline I immediately thought that TigerData is somehow related to the TigerBeetle.
Dowwie 11 days ago [-]
My experiences with Timescale revealed the need for a full time DBA expert of TSDB to make the db viable for queries exceeding more than the last week of time series data. Tiered reads barely work at all. Do you want a degree in how to use a crippled Postgres offshoot?
sgarland 11 days ago [-]
Tbf, my experience as a DBRE has been that most places should have a DB expert on staff, especially for Postgres. I’ve not used TigerData / Timescale, but IME there’s far more complexity to reason about and manage than people think.
pixl97 11 days ago [-]
Generally developers need to be watched so they don't blow up the application performance and so they reuse queries in the correct manner so you optimize things like the query cache and the indexes you have.
Query optimization is one of those places where it can be easy to get orders of magnitude performance increases.
sgarland 11 days ago [-]
Agreed, though it’s also a monstrous effort to get devs to stop chucking everything into JSON, or my new favorite hell, serializing entire classes and storing them as a BLOB.
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.
akulkarni 11 days ago [-]
I'm sorry to hear about your experience. Would love to hear more if you are open to it: ajay [at] tigerdata [dot] com.
rbaudibert 11 days ago [-]
TIL you can have GIFs as the `og:image` and Slack and friends will render them as GIFs, actually wild
LeonM 11 days ago [-]
I recon you mean that the GIF is animated? I tried pasting this with the article URL in Whatsapp (web), but it did not render any animation for me.
Care to elaborate on why you posted this?
aorth 11 days ago [-]
They learned something and wanted to share.
Did you try Slack?
11 days ago [-]
justinmitchel 12 days ago [-]
> "Our cloud offering is “Tiger Cloud.” Our logo stays the same: the tiger, looking forward, focused and fast. Some things do not change. Our open source time-series PostgreSQL extension remains TimescaleDB. Our vector extension is still pgvectorscale."
Cool!
talos_ 11 days ago [-]
IMHO, the bigger name conflict is with Tigris Data. Tigris means tiger and despite no tiger logo, they did have tiger stickers at events
You'd be surprised. Tigris is the latinized version of the name of the river in ancient Greek (τίγρης) which also means tiger in ancient Greek.
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.
The original tiger bit could have originated from some of founders’ affiliations with Princeton too.
zlib 11 days ago [-]
Timescale is much better
koakuma-chan 11 days ago [-]
They should have kept timescale
halfmatthalfcat 11 days ago [-]
Age as old as time. My favorite on is Typesafe -> Lightbend -> Akka, and by favorite, most annoying.
gregors 9 days ago [-]
Timescale is sooooo much better. What a bad decision.
orphea 11 days ago [-]
Slightly off-topic perhaps. For my use case (both short-term and long-term storage of sensors and metrics of a small Home Assistant instance) it probably doesn't matter, but what could someone recommend? ClickHouse looks kind of neat and it doesn't appear to be difficult to admin.
skowalak 11 days ago [-]
At the company I work at we manage a lot of historical data with Timescale, but we have also had good results with vanilla PostgreSQL for smaller time-series-data-sets. If you are already comfortable with Postgres this might be worth a look.
Rebelgecko 11 days ago [-]
If you like standard SQL-y type queries, timescaledv itself is a good option. Influx is another option but it has a steeper learning curve and imo it doesn't pay off
ejs 11 days ago [-]
Since this is a timescaleDB topic, would timescale not work? (With a basic DB and a few continuous aggregates running in the background?)
suyash 11 days ago [-]
I would go with InfluxDB, actually it's powers several Home Assistant apps behind the scene already for a reason.
suyash 11 days ago [-]
btw I work at InfluxData and happy to answer any question, just ask here or reach our in our forums
lukaslalinsky 11 days ago [-]
At first I thought they were sold and the new owner didn't like the original name, but it doesn't seem to be the case. I don't really understand, why would somebody change a recognizable brand.
NewJazz 11 days ago [-]
TimescaleDB will continue to be used to refer to the timeseries postgresql extension. One offering from what they consider to be a larger set of offerings.
jitl 11 days ago [-]
Because they don’t want to be pigeonholed as “just time series things”. They continue selling a product called timescale, so I don’t think it’s a loss of brand in much measure.
coldtea 11 days ago [-]
We only care for them to the degree they do "time series things".
Not for AI or other bs "pivots"
blitzar 11 days ago [-]
pivot from time to ai
jamesgresql 11 days ago [-]
Not the case!
gangstead 11 days ago [-]
Then why reference the "Agentic Era" in the title?
nelsonfigueroa 11 days ago [-]
well at least they didn't append "AI" to their name
akulkarni 11 days ago [-]
That was one of our requirements when we started discussing a name change. :-)
28304283409234 11 days ago [-]
Missed opportunity for TaigerData ;-)
doctoboggan 11 days ago [-]
> InfluxDB, and other NoSQL databases are seen as technical dead ends.
Is influxdb really seen as a dead end?
physicles 11 days ago [-]
1.x and 2.x are, which is why 3.x reinvents the product around standard tech (true SQL, Apache Arrow). It's hard to ask customers to bet on a database when, to name one reason, its query language has already changed twice.
pauldix 11 days ago [-]
InfluxDB Founder & CTO here. We worked hard to support InfluxQL in 3.x and it supports the v1 write API. Admittedly, it will be a migration to move and we haven't yet built the tooling, but we felt it was important to get the 3.0 release out even though we don't have the migration tooling built yet. Our plan is to have that available later this year.
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.
lawn 11 days ago [-]
I've been burned by influxdb abandoning their old versions one too many times and will never consider it for anything ever again.
kawsper 11 days ago [-]
Every major release of InfluxDB have been a rewrite.
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.
akulkarni 11 days ago [-]
No joke: We've had Influx customers come to us and say that migrating from Influx 1.x to Timescale was easier than migrating from 1.x to 2.x
blitzar 11 days ago [-]
I use victoriametrics now, seems to be ok
suyash 11 days ago [-]
Quite the opposite, InfluxDB 3 is the best time series database currently in the market in terms of features and performance.
suyash 11 days ago [-]
(full disclosure, I work at InfluxData so my answer is biased).
ejs 11 days ago [-]
I've been using TimescaleDB for a while as a metrics datastore. It's really proven to be great for aggregating data without a lot of hassle (using continuous aggregates, retention policies, etc).
I recommend it when you don't want/need to have separate sources for account data and your metrics/aggregate data.
tianqi 11 days ago [-]
Whenever I see a news headline mentioning that one of my critical dependencies is undergoing changes that make no technical sense, I get real fear. I feel like Jon Snow facing the army, as if I can see a tidal wave of devops work and code fixes coming my way. I really hope that these infrastructure product teams can be considering and not change something that is working well just for the sake of it. Even if they did a really smooth job, that sense of fear itself is a hurt to the brand - making me feel that this product is a source of fear.
8K832d7tNmiQ 11 days ago [-]
Why not TigerScale ?
totetsu 11 days ago [-]
Sounds like a skin disease from Game of Thrones
nwhnwh 11 days ago [-]
Tigers don't scale.
NewJazz 11 days ago [-]
Tigers are great climbers.
aduwah 11 days ago [-]
But you can scale a tiger
bobosha 11 days ago [-]
yet they do data.
nwhnwh 9 days ago [-]
Yeah, of course.
ahmadtbk 11 days ago [-]
Timescale is a much cooler name. Also heres a conversation I just had with Jippity. There are some nicer names imo.
I met these folks one time in NYC, you could tell they were onto something big & bigger.
akulkarni 11 days ago [-]
Thank you for recognizing that in us.
alexpadula 11 days ago [-]
Literally last week I was looking at the logo and was like interesting they didn't go with a name using Tiger, Cheetah, etc. Cool name, though I must say Timescale was really cool name as well.
richajak 10 days ago [-]
Most probably their new name TigerData is influenced by their lead investor during Series C funding, Tiger Global Management.
It is just my guess.
11 days ago [-]
geodel 11 days ago [-]
So we do have Tiger management, Tiger base, Tiger Systems. Now with Tiger data if they all combine we may have a TigerDBMS.
pmalynin 11 days ago [-]
Which has nothing to do with WiredTiger I guess?
heeton 11 days ago [-]
Bad choice imo, given that there is another database called tiger beetle. I assumed they’d merged when I saw the title.
eska 11 days ago [-]
Missed opportunity for the AI pivot: Taiger Data. I'll see myself out.
georgewfraser 11 days ago [-]
I talked to the timescale CTO at pg conf a few years ago and asked him what timescale does differently than a standard columnar database that makes it better suited for time oriented data. He said a bunch of things and I said “but columnar databases do those things.” Then he got mad at me.
I guess it’s just another columnar dbms after all?
I'd argue we do okay, but of course it's Clickhouses own benchmark it's hard to outperform them there.
It's also not apples to apples. Clickhouse has much less transactional guarantees and isn't postgres SQL compatible. The great thing about Timescale is that you only need one DB for all your analytics and transactional needs. Combined with pgvector postgres also handles search quite well.
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.
hodgesrm 10 days ago [-]
> Clickhouse has much less transactional guarantees ...
Is this relevant? The benchmark is just reads.
jascha_eng 9 days ago [-]
Depends on your workload? If you don't care about ACID compliance in your use-case, and query speed is all that is relevant to you probably not.
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.
hodgesrm 8 days ago [-]
I'm glad you answered as my comment was not very complete. It left out mentioning that transactions should not be expensive on reads unless you are doing something wrong. In general MVCC--which PostgreSQL uses--does not have a lot of performance overhead for this case. ClickHouse also maintains snapshots when reading, so to a certain extent they do the same work. Transactions don't seem like a very strong argument here, since you would be conceding that your implementation is inefficient.
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.
"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.
Yes, TigerData aka Timescale tried to make a fuss a few years ago comparing Clickhouse and TimescaleDB, but they failed.
freilanzer 11 days ago [-]
DuckDB seems to be the most interesting there.
qoega 11 days ago [-]
It is meant for single reader/writer workload so not meant to be used as a service
viccis 11 days ago [-]
Do you think all time series databases (like InfluxDB for example) are useless compared to "columnar databases" that "do those things" or just Timescale?
victorbjorklund 11 days ago [-]
it does sound like a pretty dumb question. Many things do similar things. That is like asking what postgres does that other sql databases doesnt.
yuretz 11 days ago [-]
Few years have passed and your guess is still wrong.
fellatio 11 days ago [-]
Unfair anecdote as you don't mention what he said before and after "he got mad" (whatever that means).
11 days ago [-]
jeffchuber 11 days ago [-]
going to be super confusing that there is now tigerdata and tigergraph - both database companies
Hey I mean I'm not super likely to use both tiger data and tiger graph, but using both tailscale and timescale has resulted in some awkward mixups
andyferris 11 days ago [-]
Also tigerbeetle!
xeonmc 11 days ago [-]
next: TigerSalamander
jeffchuber 11 days ago [-]
how could i forget!
v5v3 11 days ago [-]
"Why “Tiger”? The tiger has been our mascot since 2017, symbolizing the speed, power, and precision we strive for in our database. Over time, it’s become a core part of our culture: from weekly “Tiger Time” All Hands and monthly “State of the Tiger” business reviews, to welcoming new teammates as “tiger cubs” to the “jungle.”
Cringe...!!!
lijok 11 days ago [-]
Can you imagine joining a company and getting referred to as a tiger cub. I suspect they don’t have much in way of HR
Yeah, the kind of BS a pointy-haired boss or tech-bro considers foster "company culture"
matsemann 11 days ago [-]
Meh, it's just a bit of fun. While I don't lean too much into it myself, it's a good way of finding a company where all the grumpy hermits have self-selected themselves away.
freilanzer 11 days ago [-]
Not wanting to be a "tiger cub" introduced to the "jungle" does not make one a grumpy hermit.
coldtea 10 days ago [-]
Nah, that's the kind of corporate "fun" the grumpy hermits impose
11 days ago [-]
11 days ago [-]
rattray 11 days ago [-]
Copying what I viewed as the key parts:
> 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?
HackerThemAll 11 days ago [-]
They did not have to choose anything else - timescaledb was just fine.
0xdeafbeef 11 days ago [-]
There is already tidb :)
11 days ago [-]
11 days ago [-]
eska 11 days ago [-]
> “While I appreciate PostgreSQL every day, am I the only one who thinks this is a rather bad idea?” – top HackerNews comment on our launch (link)
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.
akulkarni 11 days ago [-]
That's fair. We referenced that quote because it captured a lot of the skepticism in the early days (and because that comment is public). No hard feelings though!
eska 10 days ago [-]
That’s fair, but I would never point out a single individual over this, even if they were really mean about it. It’s just not a good look.
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.
11 days ago [-]
be87581d 11 days ago [-]
[dead]
morelish 11 days ago [-]
Choosing a name like that made me think they were acquired by TigerBeetle. Come on like
11 days ago [-]
toddmorey 11 days ago [-]
[flagged]
11 days ago [-]
jamesgresql 12 days ago [-]
Tiger here, let's go!
Rendered at 08:35:37 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
[0]: https://youtu.be/b2F-DItXtZs
There's an element of immaturity in the style that they should probably work on.
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.
* 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?
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.
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
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.
Care to elaborate on why you posted this?
Did you try Slack?
Cool!
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.
Not for AI or other bs "pivots"
Is influxdb really seen as a dead end?
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.
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.
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.
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...
[1] https://rtabench.com/
Cringe...!!!
1: https://media.karousell.com/media/photos/products/2018/11/10...
> 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 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.