4 ms·
I have two fundamental problems with Postgres - an excellent piece of technology, no questions about that. First, to use Postgres for all those cases you have
by avmich 8mo ago
I have two fundamental problems with Postgres - an excellent piece of technology, no questions about that.
First, to use Postgres for all those cases you have to learn various aspects of Postgres. Postgres isn't a unified tool which can do everything - instead it's a set of tools under the same umbrella. As a result, you don't save much from similarly learning all those different systems and using Postgres only as a RDBMS. And if something isn't implemented in Postgres better than in a 3rd party system, it could be easier to replace that 3rd party system - just one part of the system - rather than switching from Postgres-only to Postgres-and-then-some. In other words, Postgres has little benefits when many technologies are needed comparing with the collection of separate tools. The article notwithstanding.
Second, Postgres is written for HDDs - hard disk drives, with their patterns of data access and times. Today we usually work with SSDs, and we'd benefit from having SSD-native RDBMSes. They exist, and Postgres may lose to them - both in simplicity and performance - significantly enough.
Still, Postgres is pretty good, yes.
- sbayeta 8mo agoNever heard about postgresql being written for hdds. Could you provide a source?
- avmich 8mo agoWell, take a look at the dates of when Postgres was created and when SSDs become available. Better, find articles about internal algorithms, B-trees, times of operations like seeks etc. The Postgres was initially written with disk operation timings in mind, and the point is that's changing - and I haven't heard of Postgres architecture changing with that.
- phanimahesh 8mo agoCan you share examples of new database architectures and products using them that are built for SSDs? I'm sure we have different capabilities and constraints, but I am unaware of any fundamentally different approaches to indexes.
- avmich 8mo agohttps://medium.com/@tusharmalhotra_81114/how-ssds-transformed-database-architecture-from-mysqls-hdd-legacy-to-rocksdb-and-525821c0ec53 https://medium.com/@tusharmalhotra_81114/how-ssds-transforme...
- phanimahesh 8mo agoThat blog post is very light on details can be condensed to a single line/paragraph. LSM trees are more efficient for SSDs and modern databases use them. I don't know enough to comment yet but will go read about it.
- dimgl 8mo agoSSD-native RDBMS sounds good in theory! What's in mean in practice? What relational databases are simpler and more performant? Point me in their direction!
- natnat 8mo agoThis really isn't true. You should use different parameters (specifically, you can reduce the random_page_cost to a little over 1) on a SSD but there isn't a really compelling reason to use a completely different DBMS for SSDs.