I'd love to, but I guess I'm in the situation a lot of folks are in. One of our software vendors used Oracle for its backend, so we have the privilege of having to pay for an Oracle DB, but we also don't get direct support. Sadly, we haven't hit the point where we cannot replace the damn software.
The other thing that truly ticks me off is the lack of any virtualization option for the damn thing that doesn't 8x my current cost. These damn fools actually had the nerve to call me about their HR software. I would rather buy another iSeries machine, thanks.
Oh well, it goes so well with the PowerBuilder-based database some government agency foisted on all its grant recipients. At least I don't have to pay a per CPU fee for that one.
I don't expect everyone to be able to do so. I'm simply saying that if the opportunity to migrate presents itself in a cost effective manner, do so. If scoping/requirements comes up, recommend Postgresql over Oracle at the beginning of the project.
Do what you can, where you are, with what you have.
Is there some website or technical article that compares Oracle DB to Postgres and explains the advantages of Postgres?
I know the data required for the comparison is out there, but if it's already nicely written somewhere I'd find it handy.
I think this is unlikely to be possible, and acknowledging that I don't have any postgres projects in production, but this may help.
1) except in extreme edge cases it is likely that either would be a technically capable DB for a large project.
2) Cost is a huge factor. Take your Oracle licensing costs for the life of the project. The cost of specialised hardware, and the uncertainty of its future. The cost of hosting is also a part of that. Look at the cost and availability of DBA's in your area. Now apply a discounted cash flow analysis to that, and it is not likely to beat 'free'
3) The Oracle ecosystem is looking uncertain. I can imagine the SPARC hardware you buy now not getting great support, maybe you will have to move platforms? Conversely it seems probably that you could run Postgres/Linux on any x86 VM's you want for the next decade or so!
The number one reason we stay with Oracle was that once, years ago, we had a come to Jesus moment when the database shat itself and the backups wre not working as they should have been. After a terrifying ride, some combination of Oracle support, a ton of googling and some smart in-house work repaired the damaged data and got things up and running again, literally saving the company.
Would postgres have been recoverable in that situation, that one, critical time? (its fruitless to conjecture whether postgres would have been in that situation in the first place).
I genuinely don't know. But based on experience I do feel a high level of confidence that Oracle can get me out of the shit when the chips are really down.
I'd genuinely love to know if postgres is as reliable as Oracle. Not just in day to day use, but on that once in a blue moon occasion when you really need it to be.
> we had a come to Jesus moment when the database shat itself and the backups wre not working as they should have been
So who was responsible for testing that the backups worked?
Sounds like it was equally a process failure (not verifying backups worked) as a technical one.
> I'd genuinely love to know if postgres is as reliable as Oracle. Not just in day to day use, but on that once in a blue moon occasion when you really need it to be.
If you follow best practices for postgres, have a streaming replica and streaming wal archiving (e.g. to barman) then I firmly believe it's basically bullet proof.
If the master shits itself you have the very latest transaction logs available on replica and point in time recovery servers.
Postgres also introduced support recently for native multi-master servers. This has been supported for a while by third party extensions like bucardo, but thanks to the work of 2nd quadrent there's now a multi-master implementation provided by postgres itself.
If you want a case study of a large business using postgres, look at Zalando (EU online clothing retailer) and their work with it.
That's kind of missing the point a bit. He is really looking for what all IT managers are looking for at companies of a certain size: someone to pull his kahones from the fire when and as where needed.
The real answer is: yes, there are people who can give you this level of support if you use Postgres, at I suspect cheaper rates and likely with a faster response time.
For the situation to occur that he describes with an Oracle database then a truly terrifying sequence of catastrophic events must have occurred, because Oracle is quite recoverable. But then again, so is Postgres. And under normal circumstances, Oracle support is absolutely dreadful, so I shudder to think what sort of money they paid Oracle to recover from this event!
A former employer purchased support from EnterpriseDB.
If you pay enough, you get support up to pg core devs on the phone with (I think?) a 60 minute sla 24x7. We paid them a ton of money and they definitely came through for us once, helping diagnose index corruption circa 2010-ish.
Almost the entirety of enterprise software is built on a customerbase that are buying technology in an effort to make up for failures and inefficiencies in people and processes. Buying such software arrangements are a lot closer to buying a piece of a company than a basic technology project.
The way companies approach their technology is as varied as how people approach food (and probably exercise). Some think of it as a necessary evil and eat junk food because it's cheap and sates hunger, some want tasty food from a reasonable supply chain, some cook a few things and eat out for special occasions or if they messed up and burned the food, and some keep going to chain restaurants because they are afraid / uninterested in deviating from what similar people with lack of sense of adventure do.
I'm not sure if I can make the madness of enterprise software / technology more clear than using a non-technical line of reasoning because the reasons are simply not technical at all.
Its reliable enough that tons of businesses use it for their core operations, I know mine does. When the chips are down, there is a big, talkative community using it and I know at the very least I'll find an answer, whereas if this were MSSQL I know I would just be hosed (having been in a situation like that before).
In addition, look to current cloud providers for managed mysql and postgres offerings. aws has managed mysql and postgres, as well as aurora-compatibility for both. gce has managed mysql, and i've noticed over the past few months people reaching out on hn over postgres support.
even if you think gce or aws are going to disappear in the next decade (which unlike the oracle on-prem ecosystem, is still in a big growth phase), mysql and postgres aren't. and if you ever get to the point that you need to migrate your data out of their ecosystems, they offer services to help you.
Thanks. It's very easy to find hundreds of sales pitchs about commercial products, and Oracle even creates notes about the disadvantages of Postgres [1].
Finding equivalent publications about the advantages of open source software requires more work.
There are also issues that you normally wouldn't have to worry about. The biggest is the risk of being audited by Oracle, and the threat that they will make you either purchase other products, or sue you for a lot more money.
We just got this at work too. My boss restrained himself from asking if they were calling from the Postgres Marketing Department.
(We almost entirely got off Oracle a year ago; we have one remaining instance for the Business Intelligence guys who are using something Oracle-dependent. We're working out how to charge literally everything related to this to them, or they find some software that talks to PG.)
Yup, that's a pretty decent way around things. The trick is to support Oracle with open arms when they bypass IT, but make sure that IT charges back the costs for Oracle to the business units who use it.
The business wants an Oracle DBA? He gets employed by that business unit, and they pay him/her out of their budget. The business needs their database tuned? Charge the support costs to their cost centre. They want advanced database tuning? Again, consultants fees go to their cost centre.
After a while, there's a good chance that the CEO will be asking why their profits are down. No amount of golf is worth risking the CEO's bonus :-)
1. dissing the cloud biz, pitching the world We've Doe That With 5 Nines Forever
2. Repositioning the CRUD style apps of Oracle's 1990s acquisiton spree by literally taking them off the market, and saying meanwhile, but we still know enough to tell you Cloud Competitor A is crap, so we'll give you the back end for nominal cost, because we value data above all, chances are were our customer before anyhow, We Care About Data Integrity And Availability; PeopleSoft.NEXT will make you want to come back again, it will leverage ANY cloud tech you got to enjoy whilst "out there in the wild" - "meanwhile we care you get the benefit a super back end and migration back to us will be zero pain" ; oh, and we are going properly open with web components with dotNEXT software allowing you to use components whereer you like however you like on web pages etc (This is telling customers, there is time worth waiting, BUT MORE CRUCIALLY it is telling customers they will get something they cant have with monolithic web apps from compeitors) all the while 50% of staff are there close up learning competing tech and helping Orcle customers use the Oracle DB back end to flow data etc up to busines sunits and CxOs.
3. Better way to retain talent, I am certain. The half of devs who work on competitor ware integration are being paid to learn very transferable skills (very!) . The other half get to kiss goodbye to overblown 90s CRUD and work with distributed systems at the heart of reliability which is definitely top tech forefront now when defining cloud by exposing like AWS Lambda and Azure Fabric
4. It hits the low end On Ramp of new customers - anyone using any cloud service to run any biz of any size can always look to Oracle for ensuring data integrity and reliability.
5. It hits the money no object and big corporation customers with a pivot to moving their contracts from paying for integration support to paying data scientists to extract value, and this has a new tier of pricing that can support high min value contracts and multi year contracts for that support -
6. follows the data science support pitch, Big Corps quickly get used to such support and help and insights. C Suites are addicted to this kind of rapid turnaround consultancy.
7. This Redefines Oracle as the Custodian of safe data in the cloud, and REFRESHES THE BRAND ORACLE as meaning truly Delphic Oracle, pun intended, a purveyor of data truths.
8. The On Ramp to Oracle starts EVERYWHERE THERE'S A NOTABLE B2B CLOUD SERVICE
9. IF COMPETING CLOUD COMPANIES ARE NOT OPEN (OUCH, THAT WOULD BE A BIG STONE TO THROW IN THE POND!) THEN ORACLE CAN CLAIM THIS IS NOT WHAT THE CLOUD IS ABOUT!!
10. 9 reinforces so much of Larry Ellison's cloud angst message, in a positive light that any board level executive can understand.
11. Oracle can say, OK, You Dont Have Our Tech, So We Now Compete On What You Say You Bring, and hire to ensure shaming.
12. I have to loathe personally the idea that cloud is closed cultures , and it takes a BIG company to force anything to be openly interoperable.
13.
I shall stop there, there are to many angles to what I am imagining and proposing I would do if I were Larrty Ellison.
But fundamentally i see Oracle is capable to regain the high ground and overtake the low competing grounds, of IT, any time it buckles up and puts its mouth on the line, and makes real Larry's condemnation of what the "cloud" is: cloud is neither easy reliability, nor easy (or at all) interoperability across services.
I believe Oracle would take on so many (happy) new smal customers whose needs are literally lights out so any revenue is almost free cflow, and at a Watson level, eat high level Strategic budgets that IT never gets ahold of but the accountant - consultancy majors eat instead - with teams of data scientists becoming the primary employee description you get access to when you can Oracle support.... Meanwhile they can push their optimisation products down the stack completely, eliminating much of what support often does, and I daresay they should then outsource all the trad tech support entirely, which can then be competitive, and create a positive ecosystem baseline instead of having Oracle suing support offering competitors for access to OTN.
I would LOVE to use Oracle, if they lived up to the potential they have.
Meanwhile, I learned so much in 30 years, from Oracle, how to operate as a player in the software world, they almost trained me to keep my department running happily, free from outside risks or fud, I almost could thank them, for a education I gained unpicking their sales and business techniques, that kept my responsibilities safe, even when I did elect to license Oracle for my firm.
my group billed the last Oracle deployment proposition for a full LOB disaster recovery contingency programme evaluation and priced it in units of median CxO option valuations.
Okay, that was the flippant part we kept to ourselves, but we did evaluate another BU's purported need for Oracle RAC in terms of economic impact, with a twist: we cited a board memo regarding the IT dept responsibilities that was phrased in terms of value to the corp in business continuity. We accounted for the impact of lost ROI on NREs and long term investment programmes such as select use of very high end storage kit to enable point in time recovery for virtually anything, for which we have a capacity provisioning budget, and itemised everwhere the Oracle RAC proposition was replicating existig IT budget with as yet evaluated risks. So we billed a advance iter departmental charge for a new evaluation of their proposal, plus potential HR drain on IT, plus a last killer factor: the question whether the Board should approve a diversion from a programme of IT investment secured a mere 4 years ago, which they are happy enough with to refer (indirectly) to in annual reports.
We went one further, we sent a formal request to Legal, for impact on our cient SLAs, where our systems could not be guaranteed (without new policies we furnished a budget for initial assessment and a timetable gantt chart) where we involved 3rd party liability: Would Oracle indemnify us if their systems in any way interacted with our SLAs, alternately what is the risk to that BU sales (separate document RFP sent to CFO) in event of a client crisis?
Needless to say, we were able to attach real enterprise wide costs _within the Oracle sales process itself _ far beyond their anticipated sale price, and the proposal died on the vine.
Detailed line items included inter departmental billing at contract rates for IT sitting in on planing meetings with Oracle, replete with citations from C Suite memos regarding unit costing and "matrix management", and examples of recent inter-dept. invoicing, and, the _coup de grace, a quote from Oracle themselves to provide the IT dept. the consultancy required to advise on the economic impact of a LOB data warehouse analysis installation on a non - Oracle ("greenfield"! ouch!) IT shop, so that we had from Oracle themselves a estimate at the least of their idea what time and manpower we needed to get the "best return" form that investment.
All the while, we spoke warmly about the (very real) robustness of Oracle in serious deployments, let out our misgivings of open source culture and development (we sell a commercial software service in a financial niche) and were entirely hospitable to the sales people Oracle sent. Sneakily, we led the introductions they needed, or would have needed, had we not, to use what i think is a very British expression "seen them coming from a distance".
The business where I work probably would never have existed without RDB, latterly Oracle, on VMS. I would not lightly denigrate Oracles ability, but i feel it is more like a teacher handing in a report card, bemoaning a brilliant child's talents that are being wasted, to praise Oracle in recent years.
Larry Ellison had - to my view - a superb chance when he slagged off cloud biz, quipping they did cloud since Kingdom Come....
.... Yes, now if Oracle had followed that up with letting people have full on geo clustered Oracle RAC plus bells & whistles in bundles at reasonable per user monthly simple contract rates, and explained, "Hey, we can do this, cloud is remote access, but cloud is not Five Nines and real time point in time backup when you run 100K queries a second, here are some usage budgeting plans that nobody else can dream of matching, OH AND it is Solaris/SPARC that enables this offering at this price point...."
Well, I am sure you get my drift,
I sadly think Larry was correct to dismiss, wrong to try to follow, and Terminally Wrong to not cannibalize their licensing model by making offerings that gave you true HA Oracle at low per user entry prices and linear scaled cost for size, latency, query ad query complexity rate.
What I would have done, were I Larry Ellison, would be to split off half of every product dev team to writing integrations with the competition's cloud offering.
Then I would open Per User accounted integration rates, to scoop the back end database off of any conceivable service you don't want to go down.
Every single product line, say PeopleSoft HR, I would pivot as high as half their developers to making say LinkedIN useful. LinkedIn takes 60 dollars or so per user per month, make Oracle the backend and charge 15 bucks per user per month, to let CxO folk feel happy a seriously robust back end is collating their sales interactions for one example, is how I would start my attrition of that revenue capture. If SalesForce gets 30 bucks a user on LinkedIN integration, I do not care if I get 20, I take that business away. I would target by customers who are deep int Oracle Financials, and build forecasting modules for them, to see LinkedIn data feed their analysis and forecasts.
I absolutely believe Oracle could be cannibalistic to many product revenues, whilst pivoting twice in this way:
- Pivot One: make Oracle RAC HA at least as cheap as per user SQL Server on Azure. (but with central linear scaled risers that ignore small enterprise and after say 50 users give a rational runtime fee for bigger databases)
Pivot Two: take half each product line developers, and task them to build integrations to every competitor in the same field. (this also is a twofold strategy, on one hand, make Oracle NOTCloud licensing support non Oracle uses at a low rate to get the data onto Oracle back end; then both undercut and offer price breaks for scaling DB size by adding further SLAs and support automatically as that scales up. Give No Reason for any cloud app to not have Oracle at the back end, Give a clear product cost ramp that competes with self hosting even without staffing costs DBAs etc)
Pivot Three: Take the remaining half of product line developers, and task them with Product,Next. The objective need to be make a small business accessible version of Oracle Financials, on a affordable cloud platform, and for high end, hire aggressively new data scientists to meet needs of big companies, either to develop products that make use of the cloud heterogenously or the data stores and silos and marts and all that stuff in intelligent ways, HA SLAs are throughout this a given, but now you charge per query or bulk deal.
The two biggest disadvantages of Postgres is that the options for clustering/HA/failover are no-where near as straightforward, and that there's much less tooling and information to acclimatise DBAs to working with it. I offer both those from working in shops which have adopted both at one time or another
For advantages I would cite:
1. As with Linux vendors, you have a number of options for support. You can go with a Red Hat style model from EnterpriseDB (annual fee, helpdesks and consultancy, and so on), consultancies such as LisaSoft, through to downloads and following mailing lists. While Oracle have a wide partner network, ultimately you're stuck with what Oracle decide to provide.
2. Postgres doesn't care about your platform. This is huge, huge, huge. Any conversation around Oracle DB will turn into a sales opportunity for Exa* products, OracleVM, and OEL. The Oracle DB pricing and support are hugely worse off (more expensive, less supported) on any non-Oracle product OS or hypervisor. You will either have to drag a bunch of hardware and software that wouldn't already be price/feature competitive into your life, or spend a lot of time fighting and micromanaging your DB footprint, both of which are terrible choices.
3. IME for most things Postgresql is a lot easier to use than Oracle. Per my first comment there are some cases where it isn't, much much of the set up/deploy/upgrade is much more straightforward and amenable to automation tooling (ansible/puppet/chef/etc) than Oracle.
4. Postgresql features are there or not. Folks will make a lot of the partitioning not being quite as easy as Oracle's to set up and run, but those same people are unlikely to mention how much extra $$$ Oracle partitioning costs. Or the management packs. Or the encryption packs. Or... you get the picture.
I can't really go into more detail than that, I'm afraid, since Oracle, like IBM with DB2, have fishhooks in their licenses which limit the amount of real-world information users of the product can share.
Personally, if I were starting a thing from scratch, I'd be inclined to use Postgres as a baseline and DB2 or SQLServer for anything it can't handle.
What can SQLServer handle that Postgres can't? I've only ever used the former in retail settings, where its hosed my customers over multiple times (thanks 1 core, 1GB ram & 10GB DB Size cap!) either via licensing, or edge cases where theres no community support, and the upstream software vendor told us to go fly a kite, so I'm very much not interested in SQLServer or any licensed DB, cause its a relationship ending move to say "Your database is gone, start scanning everything in the building again, sorry".
You never have to even think about licensing ever again.
So instead of a giant SPOF database server, you can give every app its own clustered pair or triple of PG servers.
(PG clustering is sorta painful to get really robust, needs some work here.)
And if someone says "but it's unsupported" ... every third-party Oracle support shop is desperate to grab some PG support business. They can tell which way the wind is blowing.
There are probably hypothetical use cases where Oracle is a better fit (it really is a very effective and powerful database), but these are fewer and fewer.
I wish there was an ERP on the market that would allow me to do that! ERP is about as locked in as a company can get, isn't it. At the moment anything involving Oracle is not under consideration
We are in exactly that position actually, and it is one of the reasons we are in the late stages of choosing a new ERP. Unfortunately that will likely be locked in and closed source too, but at least you have serious hosting options with MS SQLserver.
Mostly wholesale but with significant retail/ Mail order and telesales operations. We are relatively complex due to the multi channel nature. We have some special needs as we run a bonded (duty suspended) warehouse but they are limited. We are looking firmly in the general purpose market. Stuff like MS Nav and my current usability favorite SAP Business One. The company has limited in house tech and needs a lot of implementation support and a third party who will manage the DB
We have been using Oracle as db for one of our systems.
No other option from the vendor.
The vendor got a special agreement with Oracle that limits VM to 16 cores.
Pricing is identical to physical.. a very rare price because it's for specific use.
We had a one time fee, and annual 10% maintenance (fully managed and supported through vendor)... We have a DBA that runs some custom reports, but that's about it...
It's a very specialized proprietary system/software, so don't have any options to convert to anything else we using on our farm
We probably will move in a number of years, but it currently works for the users. I would drop them in a heartbeat just because of the multi-hundred megabyte SQL files they ship as part of the upgrades. I guess installers are hard.
The other thing that truly ticks me off is the lack of any virtualization option for the damn thing that doesn't 8x my current cost. These damn fools actually had the nerve to call me about their HR software. I would rather buy another iSeries machine, thanks.
Oh well, it goes so well with the PowerBuilder-based database some government agency foisted on all its grant recipients. At least I don't have to pay a per CPU fee for that one.