1. 6

I once visited a Postgres conference. One of the things that really stood out that Postgres’ market share compared to Oracle was measured in the single digits. Which is weird. I run a startup and for me it’s Postgres, Elastic, Go, Python, Redis, AWS etc.. Oracle doesn’t even come to mind, but somehow >90% of the market doesn’t look at things the same way I do :)

Another example is Pivotal Cloud Foundry, which to me seems like Heroku for Enterprise. Not 100% sure why you would use it, but it’s apparently a huge business.

Does anyone here have some good pointers about this part of the market? The community on Lobsters is huge, some of you must be buying Oracle, Cloud Foundry and Elastic support contracts.

  1.  

  2. 5

    I work at Pivotal on the Cloud Foundry team. I no longer work on a product team and instead work on an internal security team but I hope I can still help with your question.

    Large enterprises are trying to find ways to keep up with the speed of innovation set by their smaller startup counterparts. One of the reasons they buy Cloud Foundry is that it lets them start changing how they work. It removes the barriers that slow down their current software development and deployment processes. It pre-shaves the yak of building a PaaS for their internal applications.

    In general, (and in a more cynically) these companies buy the products from us rather than use the open source versions because of the support contracts. If anything goes wrong or they want a feature added then having someone to blame, sue, or rely on is important. In the case of Cloud Foundry, vendor specific improvements or integrations also draw customers to these custom, commercial distributions.

    1. 2

      because of the support contracts

      This hits the nail on the head. I work in the large enterprise space (those kinds of places where large scale outsourcing is common) and having a vendor who will support a product, with appropriate SLA, is critical. The fact that Oracle licenses cost in the hundreds of thousands a year isn’t important, as long as Oracle support is at the end of a phone line. Never mind that they’ll take longer to fix the issue than a skilled in-house developer who has access to the Postgres source…

      Oh, and don’t forget that Oracle will provide almost indefinite support for a product, as long as you’re willing to pay for it. See, eg, the Oracle Technology Products support coverage - “Sustaining Support Ends: Indefinite” for Oracle 8.1.7, which was released in 2000 and left extended support in 2006…

    2. 3

      At Code for America, I came into contact with many government buyers of Oracle, Microsoft, and similar enterprise products. In many cases they were satisfied with what they were buying, because they also got a solid support contract with the technology. Esri is a good example of this with a large number of happy customers who love having someone to call in for help. In other cases they were deeply unsatisfied with what they were buying, but felt that they had no choice but to go with a large vendor. Procurements could last a decade or longer and cross tens of millions of dollars, so no one on the buying side wanted to be saddled with the blame for some weird open source thing that didn’t work out. Oracle is a safe choice here because it offers a transfer of responsibility.

      At this level, what’s being purchased is not really technology so much as integration, architecture, and a “solution”. You buy Oracle because your level of interest is so stratospherically high that you don’t really know or care how it stacks up against other databases. You don’t even have developers on staff, you have analysts and they expect to configure pre-existing stuff or snap large chunks of functionality together.

      If you’re curious about a detailed government-eye-view of large technology decisions, Dan Sheldon’s Government IT Self-Harm Playbook is a worthwhile read.

      1. 2

        scrolling down through their mess of marketing, the first actual talk of technologies I found were “spring” / “jars” and then “.net”. that is pretty much spot-on for the enterprise or Fortune 100 world. while it might sound like everyone is using python, rust, node, go, or haskell, the heavy lifting and corporate dollars are still mostly Java. not so much because corporate dinosaurs move slowly, but because there is just so much momentum.

        I often suspect the database market isn’t quite as homogenous as reported, since quite a few big shops have become sick of the cost of Oracle, but their replacements, though based around postgress, Maria/My, or whatnot, are more hybrid storage systems.

        the biggest differences in the enterprise world are any (but not necessarily all) of: massive budgets for operations, huge scale, paranoid redundancy, stoic stickiness to legacy interfaces, and forced lock in due to contracts.