PostgresQL is an RDBMS and has increasingly been demonstrated as able to hold it's own against closed source rivals.

I think the OPs tossing NOSQL in there was poor form, and I think "SQL engines" could be replaced with DBAs. The world still needs RDBMS and we desperately need people who understand them from an engineering perspective.

But as an average app developer, I can scale my product to serve hundreds of thousands of people with really shitty DB architecture by simply throwing RAM at Postgres. That means Oracle corporate promises and hoards of query-optimizing DBAs are not the default for most fast (and even some moderately fast) moving startups anymore.

What can Oracle do that Postgres can't, then? Can Oracle function with less RAM than Postgres?

I think Oracle has a few features that postgres don't have.

Warning: conspiracy theories ahead - I have a suspicion that the biggest reason is so that their field agents (i.e. oracle-friendly DBAs : ) out in the field can always find some reason to choose Oracle over anything else.

Also: and this is based on once working with a Oracle shop and also listening to Microsoft guys: licenses fees can be a blessing in disguise, they aren't going to pay them anyways, their customers will and they will add 15%

> What can Oracle do that Postgres can't, then?

Provide enterprise level support. That is, they provide 24x7 support with technicians who can troubleshoot problems with the database or provide basic indexing support, etc. They also will write specific patches for specific customers as needed.

It also has more features than PostgreSQL (more indexing options, custom SQL extensions, a better optimizer), is more stable, and has a lot more developers working full time on it.

PostgreSQL is good, no doubt, and GAFA have shown that you can take an open source DB and throw engineers at it to make it handle ridiculous scale. But what if you don't have those engineers to throw at the problem and constantly patch/update the DB? Finding people qualified is going to be both hard and expensive. An average MySQL DBA can easily fetch $200 an hour for routine work, and over $400 an hour for emergencies (my numbers are about 4 years old; it's probably gone up), and never be out of work or job offers. I don't imagine a good PostgreSQL admin is worth any less.

This is exactly what was said about IBM as IBM was being left behind by low cost replacements and competitors. Both IBM and Oracle have many of the same characteristics in terms of being aggressive with customers and influential in the C-suite. But that was not enough.

Does Postgres already support distributed transactions across cluster nodes?

They don't have to be right, they just have to exist in sufficient numbers.

To be fair, most of the developers raving about ACID I have met have had trouble naming other valid use cases requiring full ACID besides the "transferring money from an account to other" that nearly every course and school uses. The thing is, most of the applications just don't need that kind of guarantees, if they can at least detect (when using BASE) when something went wrong.

Doing joins?

More seriously, I'd turn the question around. BASE requires you to think hard about a lot of things that ACID gives you for free. The benefits are better performance and scalability. But if you're not certain you need that performance, why go through the extra trouble?

(That said, it also depends of the data model. If you're certain your data is key/value without any relationships and will always be key/value, a key/value store is likely appropriate. If you have something more complex, I don't see it.)

ACID means you have transactions. And transactions are a fantastic feature. It's like a save point in a video game.

Use case for yesterday:

- create a user and it works, create a default access right for this user for one of our most important service;

- if this doesn't work, cancel everything.

Now I had the creation of user working, but the creation of the access right had some problems unrelated to the code.

Without a transaction, this bugs led to 100 of user accounts created without a default right access, and we had to clean it up after ward.

With a transaction, this bug would have not affected us in any way.

Transaction are safety net for data corruption. When you are using mongo, you have to manually do that logic again, and again and again.

In my experience, most mongo coders don't do it, and their DB is riddle with duplicates, incomplete inserts and such. Transactions give it to you, for free.

There are many other wonderful things about transaction:

- free manual rollback. Even when you don't have an error, reverting an operation is one line of code. Even if it affects many tables. Doing that with mongo or redis is terrible.

- free race condition handling. This one is huge because race condition are very, very hard to deal with. E.G: you want to limit the number of comment per day for untrusted users. You just add the comment, THEN check if you have more comments that acceptable, and if yes, roll it back. This way if your system if flooded with comments, you never have one slipping through.

- free ability to split your process in small units. You can create subtransaction inside transactions, and just say you want to rollback one but accept the other part. This give you huge granularity on your error handling.

Basically you get precise, clean, strong and easy reliability for close to nothing.

As soon has you have many untrusted users using your system, it becomes a fantastic asset.

You might want to read this article: http://hackingdistributed.com/2013/03/23/consistency-alphabe...

For instance, "C as in ACID" enables a CEO to say things like "the number of records in the personnel database should be N, the actual number of people I have hired." Or "number of cars produced should be less than or equal to the number of engines purchased." Or "at the end of the data analytics run, there should be a single summary object for each region, containing accurate statistics of sales figures." Or "every Bitcoin transfer that has been executed should be reflected in the corresponding users' wallets." In general, C as in ACID encompasses any kind of property that can be expressed over collections of records, where these properties are application-specific, user-defined, and checkable functions over total system state.

That is a very good article! I bookmarked it in 2013 for that reason. :)

The thing just is... A CEO doesn't really care whether there are 1500 or 1502 workers. Some idiot drops one engine on the assembly floor breaking it. Accurate statistics is an oxymoron. The bitcoin transfers are reliable (mathematically proven even), but does it matter if your wallet shows a wrong number in the UI for a while? I had a good friend go to ATM on a Friday night and see that his current balance was 2.4 billion euros. Next morning it was corrected, and nothing really bad happened.

For the business it is more important to find the (very rare) screw-ups and correct them. You don't really have to do it in real-time either. A 1960s style batch job is just fine.

The reason for previous is that the full ACID model system will fail with the same starting values. The difference is that it tells that end user something like "uh-oh, something went wrong and we can't process your transfer or whatever" (common with banking applications) when eventually consistent model allows the process to continue, and the screw-up must be handled at later stage. From the end user's point of view the ACID version is usually much worse.

The flip side of that is your friend could have gone on a buying spree that night.

Yes, they would have tracked it down and eventually recovered all or most of the money, but at significant cost.

Had the issue never occurred due to constraints of the system not allowing it to, time and money would have been saved.

Allowing a gap between the error condition and its remediation is an opportunity for exploit.

Most of these concepts are introduced only in the second year of a CS degree or later. Everyone knows that the truly gifted rockstar ninja founders drop out by christmas time first year.