Oracle is set to repeat the trajectory of SCO. Their primary product (the Oracle DB engine) is being displaced by the NoSQL and things like Postgres. The "next generation" of developers equals SQL engines with "old and bad", and when forced, it ends up with Postgres anyway.
Oracle used to survive in significant part by the support of the "database administrators" class. This layer of support is also becoming thinner and older.
There's essentially no way forward for Oracle. They can use hostage tactics to squeeze money out of exiting customers for a few more years, but otherwise they are irrelevant in the tech landscape.
Except for Java, that is. The current tech is powered by Linux and there isn't really anything as big as Java on Linux. Python has been pretty significant and Go is making inroads, but the default is all Java. It is going to be interesting to watch how this will play out.
> The "next generation" of developers equals SQL engines with "old and bad"
I think that what you mean is:
- they don't understand the relational model
- they don't understand the tradeoffs of ACID vs BASE
- they never bothered to actually learn SQL
- they *think* that they have "big data"
Don't get me wrong - there are compelling use cases for, and decent products for, every class of non-relational database.
But there's nothing out there that can handle the general use case like an RDBMS.
Anybody who doesn't understand that isn't qualified to be making organization-wide decisions.
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.
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%
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.
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.
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.
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.
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.
Basically, instead of innovating, or as the hip kids nowadays say, "pivoting", they just want to make easy money with stupid copyright claims and harmful tactics.
I find this strategy extremely toxic and malicious. Google may do a lot of stupid things, and people often make fun of their "don't be evil" motto, but let's be honest, the shit Oracle keeps pulling here over and over is the real definition of evil.
It's purely for profit and doesn't help in anyway to advance technology or humankind.
This layer of support is also becoming thinner and older.
It's not about age(ism) it's that Oracle stabbed them in the back by pushing cloud over on-prem where these guys (and gals) were employed. Now Oracle's biggest supporters are re-skilling to Postgres et al and stopped recommending Oracle to their organisations...
This is what is important to note; Oracle screwed their consulting partners as much as they could by pulling support and 'dev' in-house and simply taking over contracts of big clients. My previous company was hurt quite a lot when Oracle ate BEA. I still talk to clients from back then who miss our support and products as now Oracle is bleeding them dry providing crap. But it seemed like a good idea at the time I guess.
Agreed, we were stuck using Oracle at my job and it's an pain to maintain. Their cloud solutions are awful and on-premises suffered greatly. Their database engine might be solid, but everything around it was terrible. Things like PL/SQL being an unruly mess, even things like auto-incrementing columns were missing until the most recent release (12c R1). Coupled with insane licensing (arbitrarily changing the core factor for licensing) and auditing (soft limits, lots of hand-waving). It serves them right that they'd be losing out to Postgres.
What hard problems are they solving that can't be solved with OSS today (tech problems)?
I've heard things about their business apps division (business problems) and I can't say I particularly believe in their future there versus smaller focused companies.
So - I'm definitely not willing to go as far as the GP was with their statement, but Oracle's database technology is pretty amazing. I love postgres, Spark, NoSQL, etc. and think the progress they have made is amazing, but Oracle's database from a raw featureset is incredible.
- Shared-something database clustering - true scale-out database clustering without writing sharding logic into your application, worrying about hot spots, or sacrificing significant performance due to overhead
- query offload to storage for bulk reads
- Flashback - someone wrote a bad update that might have messed with some data? You can tell the database to set your view of the database back to before that update to verify, and then decide if you want to move the whole database back, or just extract the records that were changed by that query
- fine-grained permissioning - have a table with credit card numbers in it? Give everyone access to it, but the credit card numbers are all obfuscated
- replication - block-level? statement-level? real-time? real-time with delay? Whatever you want. In fact, you can say "Hey, replicate this database to another datacenter, don't make it synchronous, but don't let it get more than 10 minutes out of sync"
- also, btw, when you need to failover that database, if you're feeling really brave, oracle can do the whole thing for you automatically, because their database client will notify a watcher that a majority of them have lost the necessary access to the database, but can talk to the standby, and the watcher handles the failover
I could go on and on. There's just so much intelligence in the Oracle database platform. Would I ever pay for it? No, it's better to build applications that don't need that level of sophistication. But if you're a big company who doesn't want to write software to be smart about data storage and recovery, Oracle does an amazing job at just guaranteeing your data won't go away.
On the business apps side of things, I think their software is mostly terrible, but I also think that they do focus on problems that OSS typically has not. If you are a manufacturer of satellites, there is probably not an OSS ERP solution that will work for you. If you need to store 300,000 personnel records, there's probably not an OSS HCM solution for you.
None of this means that they're not eventually doomed nor that they're not shitty, but it is very fair to say that their software deals with hard problems that OSS has not typically focused on.
Great comment, thanks for the details on the specific tech - this is rarely captured in the regular "just replace Oracle with PGSQL" threads on HN.
I think you can add to this the fact that Oracle has been hardening the platform and building/fixing edge cases for 30 years. This goes a long way to preventing procurement departments from moving away from the "no-one got fired for buying <dinosaur-x>" model.
I heard a crazy stat that 99% of Oracle's business ($36B revenue, $9B profit) comes from the top 0.01% of customers (basically the US Govt and the Fortune 10). The average OSS start up is not going to materially affect this.
The real problem (solvable with tech? maybe?) is changing the culture in which big orgs evaluate and procure IT. Otherwise Oracle will just be an attractive exit for startups rather than competition that can be threatened...
> I heard a crazy stat that 99% of Oracle's business ($36B revenue, $9B profit) comes from the top 0.01% of customers (basically the US Govt and the Fortune 10). The average OSS start up is not going to materially affect this.
That's almost certainly not true, given my experience with Oracle's business. I think it's fine to say that 90% of Oracle's business comes from the Global 1000, but I know what some F500 bills from Oracle were, and they were in the $100m-$200m/year range, so you need a much broader spread to get to 36b
They've done an awful job of hardening their platform. Cease and desist letters to those who give them reproducible test cases because they violated some sort of copyright/license term does not harden anything other than the arteries of DBAs everywhere.
Yes I agree with Oracle's database technology being amazing. It was born in an era when disk space was expensive and the only data storing mechanism that most developers know was transactional ACID SQL stores. However we are living in an era when disk is cheap, data volumes grew way beyond a single node capacity and we have a handful of different approaches when it comes to store data on disk. We also have much better understanding on tradeoffs in this world (CAP, etc.).
I have moved a bunch of companies from MySQL/Oracle to scalable key-value stores having much better operational characteristics than the SQL ones. Was it hard? Hell yes, we had to educate developers about not having transactions, network partitions, order of operations and a bunch of things that solutions like OracleDB hides from you. Was it worth it? Absolutely, we had 99.99% yearly uptime while the previous SQL based solution was somewhere in the 90.00 - 95.00 range. Did we save money? Absolutely, the licensing cost and the fact that we do not need beefy boxes around payed off. Is this relevant to the subject as Oracle is in trouble or not? I am not sure. If the most of money coming from the government and fortune 100 than probably not.
I am in the same boat like other here on HN, I prefer to build systems myself that I understand 100%, and trying to avoid using technology like Oracle as much as I can based on the experience with support and the pricing. Again, I mostly work with startups and companies where the budget cannot be blown on SQL licenses.
The biggest caveat for oracle and other proprietary solutions is the /dynamic/ licensing/pricing models having an effect on architecture based on disk, cpu and other paremeters.
With OSS solutions, postgres/mariadb etc I have the flexibility of deploying as many nodes, disks, cpu, machines as I want without thinking of how will effect the price, and without worrying of a sales organization tracking my use. That's why I don't worry about clustering, partitioning, linking and many other features lacking.
If I'm going to plan for 100M to 2B monthly active users for a growing organization Oracle/Ms SQL aren't an option at all. For small scale of up to 10K users, they seem to have a use case for "legacy" organizations.
There are two reasons several of my clients have chosen Oracle over Postgres.
#1: Training. Oracle does training very well. If need new DBAs in-house (for security reasons etc), they got huge array of options available. The most effective options are also insanely expensive. Once paid 400k€ to get two new DBAs. They became very good at it.
#2: Clustering. Postgres is nowhere near what Oracle offers. Even with the newest releases. What Oracle offers is real multi-master synchronized replication with proper distributed locks, low latency, and it's maintainable and easy to setup. Postgres has still 5-10 years to do before they will reach feature parity on today's Oracle.
You're absolutely right about the feature set of Oracle, it really is impressive. With every release Postgres gains more of the killer features of Oracle but there is still a long way to go.
In addition to your list above I would also like to mention partitioning. it is available now in Postgres but it is much weaker than what Oracle offers, although it does improve with every release. I would love to see row movement in Postgres.
Coming from an Oracle environment and now working primarily with Postgres I notice that Postgres is much nicer to developers where Oracle seems much more oriented to DBAs. Oracle has nice tools around things like partitioning and sharding but it doesn't even have a boolean datatype! Postgres has a full selection of datatypes, indexes and handy functions like row_to_json().
Thanks for this. I've heard good things about their DB and appreciate you writing down things you've liked about it. I can see the viability there given the other comment that .01% of customers provide the majority revenue, if they need this level of sophistication.
It is so hard that a handful of opensource projects and 1x other companies solved it successfully (talking about the DB) and they bought most of the other tech instead of developing in-house. I am not sure which hard problem they are trying to solve but I am pretty sure that most of their offerings are overpriced. Oracle is here to stay as much as any other dinosaur from the past. They might be able to pivot to the cloud era (not too successfully yet) or they revenue is slowly going to decrease together with their significance.
I wouldn't count Oracle out just yet. They're still much bigger than SCO or its predecessors ever were. They're also under the same management that built the company up from nothing, whereas SCO was a new management team that took over Caldera and was trying to pivot them to the product they'd just bought from the former Santa Cruz Operation, had no idea what they were doing, and eventually settled on litigation as a business model.
(SCO, amazingly, is still continuing its litigation, despite having no products, employees, or assets remaining. Oral arguments on probably-the-last-appeal are March 22 in Denver.)
All of the largest corporations in the world run on financial or ERP systems such as SAP, Oracle financials, Microsoft Dynamics etc., which sit on top of relational databases.
While in the SV start-up world it may seem like NoSQL is taking over, the Enterprise database market is massive, and replacing the relational databases behind corporate ERP systems with NoSQL based solutions, (to the extent that is even possible/wise), will be a long time coming.
Oracle has a giant footprint in a huge number of organizations across multiple industries. Love them or hate them, (and right now there is good reason to hate then), they are not going away anytime soon, and calling them "irrelevant in the tech landscape" seems premature/myopic given their massive install base and influence in the corporate/enterprise IT space.
Oracle has a perfectly good business model which doesn't rely on OracleDB at all: they buy vertical enterprise software companies and then milk their customers.
Speaking as someone with good insight in enterprise NoSQL sales - vast majority of revenue is coming from Fortune 500s shifting off oracle systems.
Oracle customers have been very easy targets - solve the technical problem, and then give them sales people that care about their success and support people driven to solve any hurdles. I've been on the phone with ex-oracle DBAs crying from happiness, trying to explain how working with a support team that's genuinely there to help them get their job done has changed their professional lives. Those people become lifetime advocates and friends, making up a foundation that will keep the current NoSQL winners healthy businesses for a generation.
When I worked government contracting they had broad goals handed down which they must work toward without it being an explicit requirement. One of these goals? Get on top of an open source only stack for security, cost and future interoperability between other groups.
I worked on several projects where they were originally using Oracle or MarkLogic and we transitioned them to Postgres or various other, open source tech.
If the slow moving government is moving various projects away from Oracle, I would be shocked if some businesses weren't doing so as well. Now I don't know if moving away from proprietary is a trend or the more frequent than moving to them.
If you are allowed to and comfortable with it, could you share which country was that? Over the years I have looked at government projects in Western Europe, SE Asia and Australia, Europeans seem to be the ones that care the most about open source, while at the other end of the spectrum SE Asian governments are interested in it just as much as it lets them save money (much less because of "free as in freedom"). Australia seems to me kind of a mixed bag, it boasts about using Drupal because it's open source but I know that some projects are based on proprietary technology. Please note that much of the information I gathered is second-hand and may be inaccurate.
I can say from experience that in the U.S., the procurement people are definitely incentivized to look for solutions built on open standards and open source because of the ability for the government to have the option to not ever have to upgrade again, but to continue servicing this specific procurement (and this specific version) forever and ever and not be beholden to a specific vender or solution provider.
I've even seen cases where one company will sell a solution into the government and lose the maintenance contract the next year to some entirely different company who underbid the original provider -- and there's minimal slowdown in technical execution because the entire stack is open to some degree.
The government is starting to develop an allergy to vendor lock-in because of this.
United States. It may be a mixed bag as the agencies I worked with, well the groups within them I should say, were very, VERY against proprietary ANYTHING. I've never seen such a huge push back against software like Palantir. Funny thing? Almost every user I met LOVED just about all of the proprietary software and hated the contractor created, built on open source stacks, software.
Amazon is in the middle of a top-down migration off of Oracle. despite owning AWS, there are still a huge number of dependencies still running on Oracle.
Search YouTube, for "Yandex oracle to PostgreSQL". You would be shocked at how the enterprise space is just sick to death of oracle and once they actually TRY moving off it to PG how much insanely easier, cheaper, and better performance it is for most workloads that people thought they HAD to have oracle for.
Oracle DBAs are super easy to retrain to PostgreSQL because the two systems are quite similar and Postgres is catching up on features it has been missing.
You should look harder. If you have Oracle experience then brush up on Postgres and cash in because specialization in just that specific migration can probably carry you into retirement.
I also have done some Postgres deployments for a department that didn't want to follow the IT rules regarding Oracle.
I wasn't very impressed.
Specially regarding the programming language for storage procedures, GUI tooling and lack of support for distributed transactions across cluster nodes.
> which is what everyone uses nowadays anyway rather than MySQL
Um. No.
Unless they're doing something quite eccentric with it, developers will target the standard MySQL api, and the application will then work with any of the MySQL/compatible database servers:
I tend to use/recommend Percona Server/Cluster (for dev/prod respectively) but as long as the MySQL-version is compatible (i.e. the fork has the SQL/engine features your application needs) it's likely that other factors (e.g. PXC has Galera replication built in, is completely open source, and has commercial support available if you want it) will be more of an influence to the decision on which to use.
Patently false. I barely hear any talk about MariaDB whereas I still consistently hear about MySQL. Please define "Everybody" in this context, because it sounds like you've conflated it with "I".
What do you mean by "ask for a MySQL database"? If I were a client, I'd be rightfully pissed off if the developer I contracted gave me a completely different database than I requested in my stack. That's a complete breach of contract, if there was indeed MySQL on the spec sheet.
Who are you working with that would flagrantly ignore the obvious differences between SQL and MariaDB?
Personally, I've never seen MariaDB used in an instance where a simple MySQL db sufficed.
Among the many open source PHP installs for things like Wordpress, I don't know that I've seen a single install of MySQL. WPEngine, for instance, only offer MySQL.
The 10M+ pulls (and 3.8k stars) on Docker Hub suggests that MySQL is still getting a ton of use.
Facebook, YouTube and Google are still massive users of MySQL. And MySQL development is moving along (admittedly after not much for a few years). I doubt MariaDB really figures compared to MySQL in industry use, or new installs.
Don't forget Amazon Aurora, and Redshift. With the number of big name customers AWS, these products are the most scary to direct enterprise Oracle DB. Though the smaller and new tech giants of tomorrow will probably be running your Postgres and MySQLs as you mention
>> Their primary product (the Oracle DB engine) is being displaced by the NoSQL and things like Postgres.
I am not sure about the NoSQL part. I see it as more and more companies providing data access to different most-definitely-SQL databases other than Oracle. Postgres even has a migration page: https://wiki.postgresql.org/wiki/Oracle_to_Postgres_Conversi...
You may not like Oracle, but I bet they'll be around, thriving for decades.. Sure the Oracle DB is being replaced somewhat by other technologies and a shifting market to SaaS, but they are transforming the company rapidly and acquiring a very impressive and diverse portfolio of companies and starting to make large dents in the SaaS market:
https://en.wikipedia.org/wiki/List_of_acquisitions_by_Oracle
Oracle used to survive in significant part by the support of the "database administrators" class. This layer of support is also becoming thinner and older.
There's essentially no way forward for Oracle. They can use hostage tactics to squeeze money out of exiting customers for a few more years, but otherwise they are irrelevant in the tech landscape.
Except for Java, that is. The current tech is powered by Linux and there isn't really anything as big as Java on Linux. Python has been pretty significant and Go is making inroads, but the default is all Java. It is going to be interesting to watch how this will play out.