Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In terms of cost - I've always thought that one reason Oracle can charge the many millions of dollars per Server for a Database License is that, over the total cost of a project (with sometimes many hundreds of engineers), and the value of the project (Driving 100s of millions or more per year) - that the Database License cost would end up being round off error.

The corollary to this, of course, is that anybody who isn't involved in projects of that scale, is going to be far better served with Postgres/MySql.

It will be interesting to see what the uptake on products that try and fit in the middle - like Amazon Aurora - High scale and affordable.



Licenses costs are generally quite low compared to the overall price of a project, that's true.

But licenses can also be a bit of a nightmare to manage. I've seen many cases where licenses were violated due to needs for testing/development environments. It can be difficult go through the purchase process in big companies, specially if the software in question is not wildly used. Handling licenses can also be hard technically, when your licenses are tied to hardware (a MAC address for example) or configuration (hostname or IP). When migrating some legacy hosts to VMs, I had numerous headaches when dealing with flexlm servers. It can also be really annoying when you don't have perpetual licences and the editor goes down or is not able to generate a new licence for the (obsolete) version you are using.

Basically, you must add specific processes and even additional infrastructure (inventory, CMDBs) just to manage it. It can also slow down development.

I understand that in many fields, no viable OSS alternatives exist, or even could exist, specially for specialised software.

But if I can avoid proprietary, I generally do.

I'm not against paying for software, but other for of payments, like a support contract, are generally far less annoying.


They can charge it because if you really need Oracle, there really is no substitute. 12c is genuinely state-of-the-art, Exadata does things that only mainframes can otherwise do and a bunch of stuff that they can't.

There are far fewer people however that do really need it, than believe that they do... The vast majority of Oracle shops could probably switch to Postgres for less than their annual licenses, then start saving the money from the second year on...

My rule of thumb is that Postgres gets you 50% of Oracle for 0% of the price. Most of what most people need is somewhere in that 50%. SQL Server gets you 90% for 25% of the cost. I think Oracle will lose a lot of seats to SQL Server once it's stable on Linux.


> My rule of thumb is that Postgres gets you 50% of Oracle for 0% of the price. Most of what most people need is somewhere in that 50%. SQL Server gets you 90% for 25% of the cost.

Can you elaborate on what kinds of things fill the 40% difference between PG and MSSQL? Having used both PostgreSQL and SQL Server, my experience has been pretty much the other way around. When I need to do something with data in a table, PG probably has a feature allowing me to do it easily, and MSSQL probably doesn't. The simplest questions asked on Stack Overflow are answered with functions spanning tens of lines, often with various caveats.

The one area where MSSQL is clearly better than PG is GUI tooling, but even there I'm not particularly impressed. More than once have I read that someone absolutely loved SQL Server Management Studio, but the one conclusion I can come to after using it is "it works". For example, "Select Top 1000 Rows" is a fine view with autocompletion and everything, but then "Edit Top 200 Rows" has an SQL panel hidden behind a context menu, without autocompletion, and when you execute your modified query it rewrites it and removes all comments.


Can you elaborate on what kinds of things fill the 40% difference between PG and MSSQL?

SQL Server is well ahead of PG in query parallelisation and complex replication topologies, even as of PG 10.1. SQL Server is also ahead in change data capture, but PG 10 narrowed that gap. Managing a large user base is easier on SQL Server. If you have those use cases it is well worth the money.

If I need to do something clever with the contents of the table, SQL Server's embedded R is very good.

Having used both PostgreSQL and SQL Server,

Well indeed, most people only use a subset of their DB's full feature set, but it will be a different subset for each person :-) I don't really use GUI tools so I can't comment on that but I've heard that pgAdmin 4 is awful.


Thank you, that's the kind of answer I was looking for. Those are indeed not things I've worked with.

> I've heard that pgAdmin 4 is awful.

I've heard the same. I wasn't a fan of pgAdmin 3 either, so I've stuck with the psql command line.


> I've heard the same. I wasn't a fan of pgAdmin 3 either, so I've stuck with the psql command line.

In case you haven't heard of it, I highly highly recommend pgcli[1] if anyone reading this is doing the same as you and me but hasn't highly customized their psql shell yet. It's one of those tools I wish I had known about earlier.

1. https://www.pgcli.com/


Thank you, that's the kind of answer I was looking for

I love that in the HN community we can have these conversations without it descending into a platform war :-)

I did alot of Oracle up to SQL Server 2012 then just didn't need it any more, SQL Server + PG 9 and now 10 hit all my use cases for a tiny fraction of the cost. Now I wonder why so many people still pay so much for it.


Well as a postgres/sybase dba, there are several management features I miss in postgres.

For one, when there is no space left for wals, your instance juste crashes. In sybase/mssql your processes would just be suspended untill you add some disk space.

Also, spreading your databases on several disks is way easier. On postrgres adding tablespaces makes pg_basebackup lose functionality.

Those are some several limitations that the developper might not see, but they impact availlability.

Also, reclaiming unused space online can be tedious, and failover from one instance to another is not easy. You have to use 3rd party tools such as repman to do so.

All of thoses missing features have caused several outages and should be addresses in my opinion to be able to meet the needs of the most demanding workloads.

Still, I view postgres as the best solution for most business cases.


> For one, when there is no space left for wals, your instance juste crashes. In sybase/mssql your processes would just be suspended untill you add some disk space.

Are these not equivalent from the point of view of external clients?


Blocking is not normally equivalent to termination for most processes, and not all database activity is from human interaction.


> 12c is genuinely state-of-the-art

i know a lot of companies that are still on 11g. and this is not in any way state-of-the art, heck it does not even have a limit clause. It's hard to actually trust your statement that 12c is so much better, when 11g was basically trash.


11g was basically trash

Because it was lacking a tiny piece of syntactic sugar? Just use ROWNUM.


if it would've been just that... but if your "express" edition is harder to configure/install than a kubernetes cluster (the hard way) than something is really really wrong.


It's a bit more than that. Django has a lot workarounds[1] for Oracle and it's strange ways.

1. https://github.com/django/django/blob/master/django/db/backe...


No one who needs Oracle cares about quirky syntax. They care that Flashback Query or some other major feature works.


Good for them, but that doesn't reduce the maintenance burden for anyone trying to write database agnostic software. I guess that's a good business strategy if you are in oracle's position.

In any case your original quote was "Because it was lacking a tiny piece of syntactic sugar?", and I was merely pointing out that it is a bit more than some syntactic sugar.


anyone trying to write database agnostic software.

Who are these people, really? Noone tries to write language agnostic code then gets upset when it won't compile as both C++ and Java. People who try to write code that will compile on both Unix and Windows accept that they must make compromises... Or they have lots of platform-specific code hidden in a framework somewhere. So that is a silly argument.

If you are investing in a platform - and I don't just mean licenses but TCO, incl hiring experienced people - then it makes sense to exploit all of its features to their utmost and extract the most value. If you aren't doing that then you are coding with one hand tied behind your back.


We are getting a bit off point here. I agree with your overall point, but that's not what I'm arguing. I'm simply saying that there are reasons to criticize Oracle's DB offering that extends past 'limit/offset syntactic sugar', and there are a lot of quirks.

As a cheap, easy example of such quirks you can look at software that has to work around them, like Django.


reasons to criticize Oracle's DB offering that extends past 'limit/offset syntactic sugar', and there are a lot of quirks

Sure. But the point I was making is that if you really do need Oracle's higher-end features, there aren't many or sometimes any substitutes. How long have the PG crew been trying to get AS OF working? But Flashback's been in Oracle for years and if you need it, you need it. And if you don't, then Postgres is a pretty safe choice. But Oracle is very far from "basically trash" because some guy doesn't like some bit of syntax!


pgSQL is still not quite there when compared to PL/SQL.

And PostgreSQL lacks tooling at the same level as APEX, SQL Developer, JDBC/.NET drivers (specially bulk operations and distributed transactions).


> pgSQL is still not quite there when compared to PL/SQL.

Yes, but maybe it's a good thing after all. pgSQL is small, and mostly clear and restrictive, there's no bunch of imperative features and dark corners. The main point of PostgreSQL always was extendability, so it supports a broad list of programming languages for stored procedures.

To address efficiency concerns, executor's JIT is on the way - https://postgrespro.com/roadmap/56509


I work for an Oracle shop and I actively try to avoid using SQL Developer: on Mac at least, it’s a resource hog and fairly slow and, additionally, it’s autocomplete facilities are fairly flaky. These days I just use the DB integration built into IntelliJ which is much nicer. (And not limited to one DB)


If you colour between the lines, APEX is fantastically productive, agreed.


I've been part of exciting conversations with desk heads attempting to justify database licensing fees in flat/falling trading environments where traders and people are being let go.

Given those experiences, I personally stopped optimizing for today's flush tech budget. I now budget for what I know is a realistically shitty future state of affairs where we have to keep the lights on [1] while spending as little as possible.

[1] The one worse thing you can tell a trader during a 2008-level crisis than "I need more money for databases" is "you can't trade, we don't have enough capacity to handle the additional market vol".


DR, journaling, auditing & security, data integrity - at scale. These are all Oracle mainstays.




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

Search: