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 4 hours ago | parent | next [-]

Never heard about postgresql being written for hdds. Could you provide a source?

▲

avmich 3 hours ago | parent [-]

Well, 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 an hour ago \| parent [-]
		Can 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.

▲

natnat 3 hours ago | parent | prev | next [-]

This 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.

▲

dimgl 3 hours ago | parent | prev [-]

SSD-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!