Postgres is fantastic. But let's be honest about how it compares to commercial offerings.

https://old.reddit.com/r/PostgreSQL/comments/hqnafk/postgres...

"Before I start, a disclaimer: I Postgres, I’ve been a PG Applicative DBA for the better part of the last decade, and as a programmer I absolutely love the PG code base. . . It should also be said that Oracle’s products are insanely expensive, and yes, their business practices have been called into question quite a few times in the past.

Having said all that, and coming from many years of experience as both an Oracle DBA and PG DBA - comparing Oracle Database to Postgresql is almost like comparing a Cessna to an F-22. Only the F-22 can also transform into a Super Hercules and a helicopter.

Putting aside the usual issues of bugs and related incidents (both have had their fair share), the Oracle Database is a technological marvel. I can list off of the top of my head a number of capabilities Oracle has had for almost 20 years that PG either doesn’t have or just might have in the near future:

1. On commit fast-refresh materialized views, 2. Query Rewrite to Materialized Views, 3. Direct and asynchronous I/O, 4. Parallel Query Execution, 5. Oracle RAC - Multi Master without Replication, 6. Zero downtime upgrade, 7. No autovacuums, 8. Flashback, 9. Integrated In-Memory Database, 10. Autonomous Indexing, " etc.

The Reddit post is a good summary and worth a read, imho.

I've been working with PostgreSQL professionally for almost 20 years, I also worked professionally with Oracle for around 10 with some overlap between those time frames.

I can vouch for your comment largely. I love PostgreSQL and expect to work with it pretty much exclusively for professional RDBMS needs into a fairly distant future (with perhaps some SQL Server)... but there are features that were in Oracle back in the earlier 00's that PostgreSQL is only within the past few years catching up to. Partitioning, materialized views, etc. even though PostgreSQL is got these things now, the features are still not a feature-full and mature as they were in Oracle back then.

And speaking of SQL Server, the tooling and reporting capabilities there are something that I haven't seen achieved in the PostgreSQL ecosystem yet (to the point where my go-to client interface is still good old psql for lack of anything really better).

So, I think the kudos coming to the PostgreSQL team whenever a post like this surfaces here and elsewhere is definitely earned. But perspective on how far there is left to go is warranted and should be exciting to those that are building the future of PostgreSQL... that not all problems are solved and that you're not just there to oil the cogs laid down by generations past.

That is an important comment. I really like Postgres, as it is the only free RGDB allowing complex SQL (MySQL is improving), and is also reliable, but some people need to realize that the F22/Cessna comparison is not exagerated.

I professionally use both Postgres and Oracle, for many years, and can confirm that Oracle is so much more advanced.

In addition to the features you listed, I can think of : real-time query monitoring, active session history, inline function definition in SQL, global partitioned indexes, in-memory column store, much more advanced parallel execution capabilities, adaptive plans during query execution, bloom-filters, optimizer baselines, SQL macros, Exadata for tuning at the hardware level, Golden Gate for replication, Enterprise manager for monitoring...and a lot more actually.

And of course : Optimizer hints

Sounds like the F-35 might be a better analogy then. Astronomically more expensive, extensive but questionable feature set.

But a similar list in the other direction would be non-empty, right?

For example, PostgreSQL's SERIALIZABLE isolation level has actually been serializable for nearly a decade now. As I understand it, Oracle's isn't yet.

This post shows how developers (and people in general) have a difficult time with emotional forbearance when it comes to objective technological critique and being able to put aside (and recognize) personal bias.

The author had to put so much upfront to satiate and calm the crowd before embarking on his review.

We shouldn't have to do that.

We should operate with surgical precision on the way we argue and judge others. Try to double-check when we assume something of others. That does not mean we shouldn't talk about how unethical Oracle is, just that those two discussions can take place simultaneously without drama.

The more senior I become in my career and the older I get, the more I realize that the entire world operates like this. It is grim.

And to use most of these you need a Oracle consultant for 120 per hour and a 30k per cpu upgrade license.

These guys are professional robbers. They bribed Toronto city hall policitians for a 30 million dollar thing including a well known hockey player.

If you are abstracting the SQL into an ORM you can't take advantage of many of the features anyway.

Was involved in a 10,000 tps payment solution that used Postgresql to grow a 400 million company. And worked at banks where they would pay for oracle and never use half of the features. Relying on hardware based solutions for fail over and replication.

> 4. Parallel Query Execution

Available since Postgres 9.6 and getting better with every release.

If it's attempting to leverage many Oracle features, there might be some other good solutions to the problem as well - people don't have to use RDBMS to solve everything.

But, I was told (by Cantrill and echoed by HN), that Oracle is a rotten company that "ships mediocrity"?

Do they actually have the best RDBMS in the industry in terms of performance and feature set? (I guess this is a hard thing to answer given how these things can be fairly subjective)

Maybe the real problem is that it's better, but still not worth the cost (both money, and the cost of being an Oracle customer).

>"ships mediocrity"

Name me one VM that is remotely as advance as GraalVM.

I dont like Oracle as a business. People hate them for suing Google on open source / Copyright and API. But one Google is not without its fault in the case and two, whether you like or hate a company has nothing to do with its technical capability.

It seems in the tech industry, some company can do no wrong, and some company can do no right.

I have dealt with Oracle in the enterprise space, and endured their audit-turned-blackmail monetization strategies. They have a mixed bag of tech, some excellent, some mediocre - but their business practices are absolutely revolting and predatory.

> and the database for everyone else

I also love postgresql but lets not get ahead of ourselves! It's great for SQL and as a traditional relational database, but there are plenty of use cases that are better served using other models (especially if you care about _time_ as a concept, then Datomic or crux is probably better suited) [although there are attempts on making bitemporality accessible in postgresql too, like https://github.com/scalegenius/pg_bitemporal]

There is a professionally developed time series extension for Postgres. I haven’t tried it personally but it might be “good enough” for quite a few use cases just like Postgres’ full text search can be “good enough” without having to bring in the machine gun that is ElasticSearch/Solr.

I brought timescale (a postgres extension that brings time series to postgres) to my current IoT job, and it has been the biggest engineering win of my career. The tooling, community, extensions, and quality of postgres + very high performance inserts + reads has reduced costs for the business dramatically versus the previous cassandra + sql server setup. We have tens of billions of events in multiple timescale hypertables, with many thousands of inserts per second running on r5.xl nodes in k8s (4 vcpu, 30gb ram) and they don't break a sweat.

So yeah, it's "good enough".

Could you send me an email because my company is starting something similar

I realize now in after hand that we're talking about two different things. You're mentioning time series data, I talked about bitemporal databases.

Right, and it's probably "good enough" for most use cases. But, as always, it can't cover _everything_. I'm just making an argument against the sweeping argument that "postgresql is for everyone and everything"