Hacker News new | past | comments | ask | show | jobs | submit login

And liability, as mentioned in the OP, is a big issue. When you find a bug in Oracle that kills your DBMS, you open a ticket and Oracle has to provide a fix (or at least a workaround) based on the SLA.

Postgres developers, as the license says, have NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. This means you have to do one of three options:

  - hire Postgres experts into every ministry. Not very efficient.
  - create a single government agency that provides support to the rest of the government. Might easily lose efficiency, as any other bureaucracy
  - create a commercial support provider that has to earn money by selling Postgres support to private enterprises. Again, there's a risk that it will start charging the highest possible price for its services.



I actually managed to get Oracle to fix a bug once. This in quite a big organization, with a huge amount of money going to oracle. I could explain them exactly what was wrong, how to fix it, and still they denied the very existence of the bug (and cited the expensive half-working workaround other companies used at the same time). Then they ignored what I told them and fixed it in a way that did not fix it. Then they fixed it, and did not allow us to use the fix until it was officialized in a real service pack.

The whole process took multiple months, reading all contracts I couldget my hands on, answering the phone at 3AM, a lot of patience, and treating Oracle as a student who was 2 weeks late with their homework. After that, all oraclies at the organization were completely awed because I was the first person ever who managed to get a usefull new patch out of oracle's service.

If you want results, get Postgres. If you want someone to blame, get Oracle.


> If you want results, get Postgres. If you want someone to blame, get Oracle.

I've twice offered fixes to Oracle (didn't even get a thank you); countless times I've had to find workarounds; and I've lost endless hours working with support to get things fixed.

I have no respect for Oracle software. It gives me nothing but headaches. I can't really just blame Oracle, because I have to keep my organisation working. I just wish I could get rid of it.


> If you want results, get Postgres. If you want someone to blame, get Oracle.

It's the someone to blame part that's important in big corporate bureaucracy. It's being able to tell your boss "We've done everything we can, it's in Oracle's hands now" limits your own liability vs. "We need to fix this ourselves, and haven't solved the problem yet."


Yeah, the difference between being a child and being a man.


> you open a ticket and Oracle has to provide a fix (or at least a workaround) based on the SLA.

Have you received reasonable help in reasonable time that way? How big was the investment on your company's side to make that happen?

It was a meme on every DBA team I worked with.


"Oracle has to provide a fix" also means that you can tell your boss that you're doing your best and it's up to Oracle now.

It's not just about fixing the problem, but about protecting your own career. "No one ever got fired for buying IBM".


That's an obvious, typical mechanism. A sad one.

Now circle back to the main thread - you invest some multi-million budget yearly to have support, but you get just an excuse.

People are expensive, but not "oracle expensive". Plus there are many smaller shops that sell support for opensource databases, I'd you don't want to hire senior people.


The reality matters far less than the vaguely worded promises CEOs think they hear when they're sold on switching to Oracle.


Yes, we have received reasonable and timely help when a wild ORA-600 appeared (with an Oracle engineer arriving on site to diagnose and apply the fix), but you are right, we had an 80-core POWER machine running this database.


> as any other bureaucracy

It is not bureaucracy vs magical efficiency. There is the same issue in any large organisation, even corporations. In practice I don’t think it would be as bad as you suggest. Having an agency focused on providing support instead of sending money to shareholders also limits other kinds of inefficiencies.

> Again, there's a risk that it will start charging the highest possible price for its services.

That is exactly the situation we’re in, where governments are tied and dependent on single providers (be it Microsoft, Oracle, SAP, or others). This solution would create competition opportunities by opening a market, it does not need to be a monopoly.


> Again, there's a risk that it will start charging the highest possible price for its services.

So you switch to a different commercial service provider, problem solved. The software is open source, they can't lock you down in a predatory contract. Worst-case scenario, you can always choose to fork it yourself.


“ create a single government agency that provides support to the rest of the government. Might easily lose efficiency, as any other bureaucracy”. As opposed to huge corporations that are known to be the pinnacle of efficiency…


You missed one: hire one of the many existing providers of Postgres support services. Postgres have a big list of these providers. [0]

I can't comment on how well they perform in practice compared to the conventional monopolised support model that closed-source software tends to offer - perhaps better, perhaps worse - but at least in principle, the solution is there.

[0] https://www.postgresql.org/support/professional_support/


There's at the very least some freedom of choice, which makes it so if you don't get a good provider you can see if a different one meets your needs

If Oracle support isn't all the way there the alternative is basically to kick rocks


> There's at the very least some freedom of choice, which makes it so if you don't get a good provider you can see if a different one meets your needs

Assuming decent providers exist, yes, that's an advantage.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: