Kind of, with caveats. For one "extensions can interfere with each other and cause incorrect behavior" [1], and the practicallity of implementations varies. Say, Cypher queries using AGE can be order of magnitude slower than using a dedicated graph DB [2].
Yes, you can drive a Ford Falcon coast-to-coast, but how much gas are you going to spend? Postgres is a solid database but has roots in the 80s. Optimizing for modern hardware would reduce hosting costs and improve efficiency. [3]
This isn’t criticism of Postgres as a database but of the idea that it’s inherently sufficient for all use cases.
Of course there are better time series than Timescale. Better graph databases than AGE. Better GIS databases than PostGIS. The point made when it comes to Postgres is 9 times out of 10 you don’t need better thing. And unless you have that compelling optimization already ready to go with receipts to back it up, probably you should pick Postgres
Not disagreeing, but for more context. These blog posts also have to be taken with a grain of salt as the authors obviously have their own project to promote, coloring their point of view.
The algorithms detailed in the graph DB post can be run on top of PostgreSQL, though one has to do some of the work of the DBMS themselves (maintaining indexes, transforming query to correct form). It's extra work and requires some knowhow, but up to some extent it works "well enough".
Similarly, the CedarDB comments, that could be boiled down to the lack of column major batched executor model, are mostly applicable to analytical queries. Point query and traversal type workloads are not as different. There are various projects that work around this to some extent by sticking DuckDB into PostgreSQL . This gets vectorized execution on mass data scans, which is usually enough to get into the right ballpark.
The point being that the amount of use cases where Postgres is sufficient is highly dependent on the skill and time put into it. And at some point the extra organizational cost of going heterogeneous is going to be worth the payoff. The hard part is figuring that out ahead of time. Which is why my recommendations for starting developers is to just use Postgres until it starts to hurt, then optimize it to work well again and use the insight gained to see what functionality needs to be peeled off into a specialized system.
> Yes, you can drive a Ford Falcon coast-to-coast, but how much gas are you going to spend? Postgres is a solid database but has roots in the 80s. Optimizing for modern hardware would reduce hosting costs and improve efficiency.
This is disingenuous. If you’re comparing Postgres to CedarDB, a more apt analogy would be Postgres is a late model Ford F-150. A utility vehicle with roots in the 80s but continuously improved since then. Not the most efficient vehicle or the fastest, but has lots of utility and great reliability. People have collectively driven F-150s for billions of miles.
And CedarDB is a concept car that some guy built in his garage. It might be efficient but it certainly isn’t proven to be reliable like Postgres is.
If I’m taking a coast-to-coast trip, I’m driving the F-150. I might not get there quickly or efficiently, but I’m sure I’ll get there. And if my F-150 breaks down, there are thousands of mechanics between the coasts that can help me get back on the road. If I take the CedarDB concept car, when it breaks down there are only one or two people that can help me, and they are thousands of miles away.