3 ms·

I understand the sentiment here (and agree PSQL will get you quite far) but this post is completely devoid of any actual content/meaning, examples etc. This is

I understand the sentiment here (and agree PSQL will get you quite far) but this post is completely devoid of any actual content/meaning, examples etc. This is a literal shitpost.

zooq_ai 2y ago
Not sure why you are downvoted. One of the biggest concerns about any DB is speed of query execution. Today a decent app/site can generate terabytes of machine data that you need to analyze. There is a massive difference in usability of a query that takes < 5 secs vs even 5 minutes. So, some benchmarks of speed vs major use cases would have been ideal. I understand, general purpose DBs can't be the best, but I can compromise for 80%. If it's 50% or less, then I really have to question that choice.
- jamesgresql 2y ago
  (Author here!) I'd compare performance to what you need, not to other technology. But also, point taken. The article this comment thread describes also needs to be written.
- simonw 2y ago
  If you're generating terabytes of analytical data you should be using a different stack for analyzing that than you do for running your production workload. (You could still use PostgreSQL, just not the same PostgreSQL servers that are running your user-facing features.)
  - zooq_ai 2y ago
    That's my point. If Postgres is only 60% performant compared to Clickhouse, I have no choice but to go with Clickhouse.
caleblloyd 2y ago
I don't understand why corporate blog posts that put memes between every other paragraph still exist. I especially can't stand the animiated gifs.
jamesgresql 2y ago
Author here, this is obviously a high level post! There are many, many posts about how Postgres with different extensions can get you different things. I didn't want to go down that path for this article because I didn't want it to end up as a sales pitch. The article you describe needs to be written, but it's a follow-up in my mind (and much more technical, for a slightly different audience).
akulkarni 2y ago
(Timescale co-founder) James did put a lot of thought into this post. I saw multiple iterations of it before it was published. I think calling it a shitpost is being unkind to him. I think we just find that some developers don't like reading long posts, so he kept this one short :-) But if you want something with more length/depth, here is another one we recently published: https://www.timescale.com/blog/postgres-for-everything/ https://www.timescale.com/blog/postgres-for-everything/

I understand the sentiment here (and agree PSQL will get you quite far) but this post is completely devoid of any actual content/meaning, examples etc. This is a literal shitpost.

zooq_ai 2y ago

Not sure why you are downvoted. One of the biggest concerns about any DB is speed of query execution. Today a decent app/site can generate terabytes of machine data that you need to analyze. There is a massive difference in usability of a query that takes < 5 secs vs even 5 minutes. So, some benchmarks of speed vs major use cases would have been ideal. I understand, general purpose DBs can't be the best, but I can compromise for 80%. If it's 50% or less, then I really have to question that choice.

jamesgresql 2y ago
(Author here!) I'd compare performance to what you need, not to other technology. But also, point taken. The article this comment thread describes also needs to be written.
simonw 2y ago
If you're generating terabytes of analytical data you should be using a different stack for analyzing that than you do for running your production workload. (You could still use PostgreSQL, just not the same PostgreSQL servers that are running your user-facing features.)
- zooq_ai 2y ago
  That's my point. If Postgres is only 60% performant compared to Clickhouse, I have no choice but to go with Clickhouse.

caleblloyd 2y ago

I don't understand why corporate blog posts that put memes between every other paragraph still exist. I especially can't stand the animiated gifs.

jamesgresql 2y ago

Author here, this is obviously a high level post! There are many, many posts about how Postgres with different extensions can get you different things. I didn't want to go down that path for this article because I didn't want it to end up as a sales pitch. The article you describe needs to be written, but it's a follow-up in my mind (and much more technical, for a slightly different audience).

akulkarni 2y ago

(Timescale co-founder) James did put a lot of thought into this post. I saw multiple iterations of it before it was published. I think calling it a shitpost is being unkind to him. I think we just find that some developers don't like reading long posts, so he kept this one short :-) But if you want something with more length/depth, here is another one we recently published: https://www.timescale.com/blog/postgres-for-everything/ https://www.timescale.com/blog/postgres-for-everything/