Hungry termites nibbling at Oracle's foundation | Hacker News Reader

Hungry termites nibbling at Oracle's foundation

theregister.co.uk

35 pointsmwaci21 comments

Aside from the simple fact that I'm experienced and comfortable with Oracle's competitor databases and don't need them, you know what keeps me away from Oracle? Their reputation.

Oracle the company have managed to spend several years convincing me that their software licencing is expensive and designed to trap me into needing extra expensive add-ons, and that their management are litigious predators out to shut down innovation by whatever means.

Quite frankly, why would I build for their platform?

What the article misses is a discussion of the core reasons keeping folks with Oracle. I know a little about that - sometimes eventual consistency is not an option and you just need to max the performance on an ACID system. Some folks just need a throat to choke.

But I'd like to know how many other reasons there are.

Some other reasons:

* Large sales teams; don't underestimate the impact that a sales rep can have on a company's technology purchasing decisions, especially outside the world of engineering-heavy startups

* An ecosystem of engineers in the U.S. and all around the world who are provided training and certification specifically in Oracle products - this gives them an incentive to suggest Oracle products to the companies they work for (or to keep these products in place)

* A perception (sometimes correct, sometimes not) that software for which the code is tightly controlled and kept by a company with a good reputation in enterprise computing will be 'better' in some senses (performance, security, usability) than open source alternatives

Sometimes it might come down to things like NoSQL vs relational, ACID compliance etc, but bear in mind that there is a huge ecosystem of (less-tech-savvy) companies out there each of which need HR, accounting, and a myriad of other internal or hosted services - and Oracle's sales teams (as with any other sales-oriented company) will have pipelines built around these companies as prospects.

We run our ERP/MRP on Oracle ($millions in licensing/maintenance) but our manufacturing operations on PostgreSQL (FOSS DB and homegrown software). <shrug> One is not necessarily "better" than the other, but it sure is nice not to have to rely on an enormous, leeching, sales-driven corporation for a core system.... We have tended to use MSSQL+C# historically for business apps, and it doesn't sit well with the people writing checks when you tell them you need multi-$k extra for the DB license to run their process automation utility (especially with MS's new 2012 licensing model). It doesn't sit well with the CIO when the alternative is a six or seven figure EA.

A company like Stackoverflow is nothing like a large corporation in terms of apps/DBs.

Have you tried the ADO adapters for Postgres? How'd you like them?

I work on an oracle-based system with roughly a thousand tables and 200.000 lines of PL/SQL code. What keeps us on oracle is:

1. We know it well. It is easy to develop for because it's just SQL on a single server.

2. In traditional ACID transactional processing, our core business, it performs quite well. Even mediocre queries often perform well. We've never had a customer or use case outgrow a single oracle db yet. Part of the reason oracle is so expensive is that you need very few servers if you properly design your db architecture.

3. Our customers already know how to deploy it, which makes rolling out our product much easier. It is proven and well-understood technology. Often they already have an oracle server for us to share.

4. Our product is designed around oracle and ACID. Migrating to an alternative would be painful (if moving to an ACID alternative like postgres) or horribly painful (if moving to a BASE database).

I think people often make the mistake of looking at the single license cost of sql server or oracle and assuming they're more expensive than the <insert favorite alternative> nosql db of the hour when you add up all the costs. I used to mock microsoft for bringing up TCO, but i have to admit it's a fair point. Stackoverflow runs off of a mirrored pair of sql server instances. You have to wonder how much servers they would need and how much extra development it would have cost to handle the same load on an eventually consistent alternative.

My personal opinion is that you have to choose up-front whether to scale up or scale out. Scaling up means paying for oracle or sql server and having a simpler development model because you have a single db instance. Scaling out means going for nosql and taking some of the reliability and synchronization work into your codebase. I don't think companies like oracle are selling the development advantages of scaling up very well, probably because they're not developer-oriented. The strategic mistake oracle continues to make is to alienate devs. They could build a strong case for oracle over nosql, if they cared about developer relations.

Interesting. Where do you put postgres in this landscape?

My opinion is that if you're going the rdbms route, you should keep everything on a single instance (mirrored to a hot backup ofcourse). As soon as you start managing a menagerie of servers with intricate programming logic to shuffle data back and forth, the nosql solutions will be a better fit. So, for any rdbms i would advise using it where it can handle the load on one instance, or possibly a few with a very simplistic sharding model (e.g. we never shard the schema, but we do host different customers on different oracle instances, without any data shared across customers).

I haven't worked enough with postgres to know what loads it can handle, but i'm sure there are plenty of cases where a single instance is just fine.

How do you work out what load Postgres can handle on what hardware? (Same question for anyone here who knows MSSQL)

Scaling up means paying for oracle or sql server and having a simpler development model because you have a single db instance. Scaling out means going for nosql and taking some of the reliability and synchronization work into your codebase.

Ignoring some of the specific details and focusing on the underlying point here:

Having had to work with both ACID and BASE systems extensively, the above point strikes a chord with me. Those of you who haven't dealt with both in anger, take heed of it.

BASE is a lot of code and reasoning to work with properly, and you're sacrificing the many knobs, tools, and easy ad-hoc queries (read: simpler debugging) that the common ACID systems have to get it. Common ACID systems are well understood, so there are many fewer surprises in wait. Furthermore, those systems are mature and have walked the inescapable trail of tears to get there; data is the lifeblood of most businesses, so it's not a place to take risks.

I'd rather work with ACID. BASE is for when you really need it (and when you really need it, you'll know).

Distributed systems are hard, including for database vendors. So when the database "doesn't scale", the database gets blamed.

It's a bit like blaming Boeing for gravity, then swearing only to use fleets of microlights to relocate your shipping containers.

I've been slowly coming to thus realization every time I read about another gotcha with MongoDB or any of other upstarts who are running into problems Oracle solved 15 years ago. I'm surprised Oracle isn't leveraging BerkeleyDB more to combat the NoSQL upstarts. It's languished since the acquisition even though it had a big headstart.

They've wrapped berkeleydb as 'oracle nosql', but haven't gotten any traction, probably because they don't know how to approach that market.

http://www.oracle.com/technetwork/products/nosqldb/overview/...

> Stackoverflow runs off of a mirrored pair of sql server instances. You have to wonder how much servers they would need and how much extra development it would have cost to handle the same load on an eventually consistent alternative

Considering they really don't need ACID and the amount of complexity their cache layers add, it would probably be much simpler to develop, maintain and operate. Seriously, their model is the textbook example for non-relational datastores.

Lock in due to the usage of proprietary features like PL/SQL. Switching costs are too high for existing systems.

Oracle is not just a database company anymore.

This. These days, Database is one of hundreds of products covering every enterprise market under the sun. Their emphasis is in selling you products for specific needs, which of course will use the database underneath. In that sense, developer relations are less important, since

I assume all of these companies are moving some of their data off Oracle.

In any event, Oracle is a bully.

I think most of the companies only do business with them, because they have to (as sometimes there is no alternative). What Oracle will probably learn painfully in the future, is that folks will be moving away as soon as they get the chance.

The NoSQL hype currently is in the "Trough of Disillusionment" phase, not?

Actually no, it's in the "we figured it out and use it instead of hyping it" phase.

This would be "Slope of Enlightenment": http://en.wikipedia.org/wiki/Hype_cycle . I venture to doubt that NoSQL has reached this phase yet.

Reply on news.ycombinator.com