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".
Postgres is eating the database world
51–60 of 147 posts
Re: Postgres is eating the database world
#52I would like to keep my data in Postgres (OLTP purposes), but run analytical queries against the same datafiles in Snowflake/DuckDB fashion.
The analytics part should scale independently. Often this is only needed occasionally, so scale-to-zero (like Snowflake) would be great.
Re: Postgres is eating the database world
#53It'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.
Re: Postgres is eating the database world
#54Postgres is far from perfect:
- The codebase is old and huge, accruing some heavy technical debt, making it a less than ideal foundation for iterating quickly on a new paradigm like AI and vector databases.
- Some ancient design decisions have aged poorly, such as its one connection per process model, which is not as efficient as distributing async tasks over thread pools. If not mitigated through an external connection pooler you can easily have real production issues.
- Certain common use cases suffer from poor performance; for example, write amplification is a known issue. Many junior developers mistakenly believe they can simply update a timestamp or increment a field on a main table with numerous columns.
So, yes, PG is one of the best compromises available on the database market today. It's robust, offers good enough performance, and is feature-rich. However, I don't believe it can become the ONE database for all purposes.
Using a dedicated tool best suited for a specific use case still has its place; SQLite and DuckDB, for instance, are very different solutions with interesting trade-offs.
Re: Postgres is eating the database world
#55Postgres is still single-node-first, and while Citus exists I'm skeptical that it can ever become as easy to administer as a true HA-first datastore. For me the reason to use something like Cassandra or Kafka was never "big data" per se, it was having true master-master fault tolerance out of the box in a way that worked with everything.
[deleted]
Re: Postgres is eating the database world
#56Earlier quoted context omitted.
Its got a lot better over the years. 25+ years ago MySQL was fast and easy to admin but didn't have rollback and a bunch of other features. At the same time Postgres had the features but was horrible for performance and usability. Those days are LONG gone. Mysql obviously has all the features and PG is great to admin and the auto-vacuum works well out of the box. I run a bunch of clusters of pg servers around the wor…
> PG is great to admin What do you use for it? Is there anything like phpmyadmin for postgres with similar simplicity?
Pretty much the same as mysql. https://wiki.postgresql.org/wiki/PostgreSQL_Clients#Web_Clie...
Re: Postgres is eating the database world
#57Postgres is far from perfect: - The codebase is old and huge, accruing some heavy technical debt, making it a less than ideal foundation for iterating quickly on a new paradigm like AI and vector databases. - Some ancient design decisions have aged poorly, such as its one connection per process model, which is not as efficient as distributing async tasks over thread pools. If not mitigated through an external connect…
I believe that there are contributors currently working on a one thread per connection version of PostgreSQL. It's a huge amount of work so I wouldn't expect it to be released tomorrow.
Regarding wide updates, I believe that HOT updates already partially solve this problem.
Re: Postgres is eating the database world
#58Earlier quoted context omitted.
Its got a lot better over the years. 25+ years ago MySQL was fast and easy to admin but didn't have rollback and a bunch of other features. At the same time Postgres had the features but was horrible for performance and usability. Those days are LONG gone. Mysql obviously has all the features and PG is great to admin and the auto-vacuum works well out of the box. I run a bunch of clusters of pg servers around the wor…
> PG is great to admin What do you use for it? Is there anything like phpmyadmin for postgres with similar simplicity?
Coming myself from MySQL to Postgres I found PgAdmin (https://www.pgadmin.org/screenshots/#7) easy to use
Re: Postgres is eating the database world
#59> not to mention its ElasticSearch grade full-text search capabilities.
I played with postgresql a while ago to implement search. It's not horrible. But it's nowhere near Elasticsearch in terms of its capabilities. It's adequate for implementing very narrow use cases where search ranking really doesn't matter much (i.e. your revenue is not really impacted by poor precision and recall metrics). If your revenue does depend on that (e.g. because people buy stuff that they find on your website), you should be a bit more careful about monitoring your search performance and using the right tools to improve performance.
But for everything else you only have a handful of tools to work with to tune things. And what little there is is hard to use and kind of clunky. Great if that really is all you need and you know what you are doing but if you've used Elasticsearch and know how to use it properly you'll find your self missing quite a few things. Maybe some of those things will get added over time but for now it simply does not give you a lot to work with.
That being said, if you go down that path the trigram support in postgres is actually quite useful for implementing simple search. I went for that after trying the very clunky tsvector support and finding it very underwhelming for even the simplest of use cases. Trigrams are easier to deal with in postgres and you can implement some half decent ranking with it. Great for searching across product ids, names, and other short strings.
Re: Postgres is eating the database world
#60> not to mention its ElasticSearch grade full-text search capabilities. I played with postgresql a while ago to implement search. It's not horrible. But it's nowhere near Elasticsearch in terms of its capabilities. It's adequate for implementing very narrow use cases where search ranking really doesn't matter much (i.e. your revenue is not really impacted by poor precision and recall metrics). If your revenue does de…
That's true for the kernel, How about extensions such as ParadeDB BM25 https://www.paradedb.com/ + PGroonga https://pgroonga.github.io/ + PG Bigm https://github.com/pgbigm/pg_bigm ?