91–100 of 147 posts
It's not a best practice, it's a fad. 99% of people who recommend or use Postgres barely know how to use it. Another trendy database will come along and you'll stop seeing all these posts about it. Happens every decade. I'll link back to this post in a few years with "I told you so".
It’s been 40 years for Postgres. A database is not some trendy ReactJS library.
It's not a best practice, it's a fad. 99% of people who recommend or use Postgres barely know how to use it. Another trendy database will come along and you'll stop seeing all these posts about it. Happens every decade. I'll link back to this post in a few years with "I told you so".
You're not wrong here, although you could just as easily say "99% of people who recommend $DB barely know how to use it."
Databases remain a mysterious black box to entirely too many people, despite the three largest (SQLite, Postgres, MySQL) being open source, and having extensive documentation.
I've come to the conclusion that most devs don't care about infra in the slightest, and view a DB as a place to stick data. When it stops working like they want, they shrug and upsize the instance. This is infuriating to me, because it's the equivalent of me pushing a PR to implement bogosort, and when told that it's suboptimal, dismissing the criticism and arguing that infra just needs to allocate more cores.
Earlier quoted context omitted.
Well 25 years ago was pretty much (December 1998) when "LAMP"[1] was defined and that was originally Linux, Apache, MySQL and PHP. So Postgres and Python were not the obvious choices back then. [1] https://en.wikipedia.org/wiki/LAMP_(software_bundle)
In my personal experience of being around back then, postgres and python were still considered "technically better", but such a massive pain in the ass to install (especially on cheap shared hosting where it was often actually impossible to install) that only the most masochistic people would even try. I myself wrote a fastcgi implementation in PHP which would allow a web server which only supported php to call pytho…
PHP has been very good at reinventing itself and being its own biggest competitor. Zend outcompeted PHP3, PHP5 outcompeted PHP4, PHP7 outcompeted PHP5 and so on. Compare a site written in modern idiomatic PHP8 using something like Laravel to a site written in classic PHP3 and they might as well be two different languages.
Earlier quoted context omitted.
Materialized views with pg_cron to refresh them? (Or even just cron and your usual interface, if you don't want to install something extra)
This solves the same problem, just not as well, the idea of an incrementaly maintained view is that only the update needs to be computed, so a count will increment or decrement as rows are inserted or deleted. It means complex views that could take minutes or hours to calculate from scratch can be kept fresh in realtime.
>As DuckDB’s manifesto “Big Data is Dead” suggests, the era of big data is over. I have been stating this since at least 2020 if not earlier. We are expecting DDR6 and PCI-E 7.0 Spec to be finalised by 2025. You could expect them to be on market by no later than 2027. Although I believe we have reach the SSD IOPS limits without some special SSD with Z-NAND. I assume ( I could be wrong ) this makes SSD bandwidth on Se…
Postgres is such a great tool. The feature I'd love to see added that has been kicking around the mailing list for ages now would be incremental view maintenance. Being able to keep moderately complex analysis workloads fresh in realtime would be such a boon.
It's not a best practice, it's a fad. 99% of people who recommend or use Postgres barely know how to use it. Another trendy database will come along and you'll stop seeing all these posts about it. Happens every decade. I'll link back to this post in a few years with "I told you so".
It’s been 40 years for Postgres. A database is not some trendy ReactJS library.
Earlier quoted context omitted.
That feels a bit like hindsight talking. Linux perhaps, but were Python and Postgres really the obvious good judgement choices 25 years ago? Every other choice was poor judgement?
Well 25 years ago was pretty much (December 1998) when "LAMP"[1] was defined and that was originally Linux, Apache, MySQL and PHP. So Postgres and Python were not the obvious choices back then. [1] https://en.wikipedia.org/wiki/LAMP_(software_bundle)
Not fashionable by any means - but still feasible to maintain unlike Windows IIS / C++ or Oracle / Perl / Flash.
Alright I'm convinced, I'm using postgres for my next project. Anyone have any experiences with it and Entity Framework Core?
But Postgres is a work of art, and compared to all the other relational database options, if it's ultimately crowned the king of them all, it'd be well deserved.
I'd also say that the PG protocol and the extensions ecosystem are as important as the database engine.