Poll: What database does your company use?

Oracle costs at least twice as much as any other databases. Yet companies still buy it. Why do people buy things that cost twice as much? Hint: it's better.

Forget price for a moment, any feelings you might have for Larry Ellison, the good/evil nature of the company, or whatever. Consider the software itself.

Many people aren't all that familiar with the basic things a database is supposed to do. The list is large. I can't possibly give it justice off the top of my head, but here are a few that come to mind: make it possible to see data in a consistent state (as of a single point in time), without being blocked, even as other people are changing it; support "transactions" -- a group of requests that either all succeed or all fail -- so that the database cannot end up in an inconsistent state; guarantee recoverability to a consistent state even when people change their minds, statements fails, power fails, hardware fails, or all of these things happen at the same time; and many, many other things like security, support for the relational model, SQL, joins, etc. Real databases aren’t simple key-value stores.

Historically, Oracle obtained a huge lead in market share because it delivered the most complete mix of these basic things long before anyone else.

Something not widely recognized, but that should be obvious to programmers, is that low-level architectural decisions have a huge impact on how well a database performs these basic duties. Oracle maintained its lead for a long time because it got many of the low-level architectural decisions right. It is really hard to catch Oracle if you are trying to polish up a bad locking model, for example. Oracle still does the basics better than most. That, in and of itself, is a reason to consider Oracle.

Oracle remains viable, even as others continue to catch up, because Oracle builds on its solid foundation by adding additional capability and features relentlessly. I challenge you to read the new features guide for any new release of Oracle and to remember just the names of 20% of the new features. The Oracle documentation, as of 6 or 8 years ago (10g), was 40,000 pages. No telling what it is now. I can tell you this. If you have something you need to do with databases, Oracle probably figured out how to do it a long time ago.

I, personally, am a huge fan of PostgreSQL (and it’s freeness), but I recognize that Postgres is never going to be able to touch Oracle in features. It’s impossible. Working with Postgres is just going to require a lot more manual labor. Some things aren’t going to be possible. Performance may just have to suffer sometimes. Let’s hope Postgres does the basics well (it does). That’s the most important thing. But when it comes to building spacial indexes on hierarchical dimensions, or whatever, Postgress just isn’t going to have a feature for that. I’ll have to figure that one out for myself.

One key point: if you need to build a large, high-performance, data-driven application that provides nearly instantaneous response for thousands of simultaneous users, Oracle is one option that can get the job done. If you need to build something huge, say billions of rows, that provides nearly instantaneous response to dozens of users, Oracle is one option that can get that job done. So no wonder that some companies consider Oracle.

The last thing I’ll mention is that it takes a lot of time to learn something like Oracle. I would be surprised if after a year of using it, for example, that you can really make it hum better than any of its top competitors. If you do use it for a while I think you’ll find that it is really good at the normal things and in a different league when it comes to the unusual things. This comes in handy when you are being paid to get things done (by a company that can afford Oracle) -- hence the reason that most startup-oriented people don't have much appreciation for Oracle.

DB2 :)

> But the relational model doesn't align well with object-orientated programming so you have an ORM layer that adds complexity to your code.

The mismatch comes about for a number of reasons:

    * OOP has no formal basis so it can't be reliably transformed into relational terms.
    * OOP is identity-bound -- each object is essentially
      an address in memory, not a relation in a set.
    * The biggie: OOP mixes data with behaviour.
      Relational does not.

> How would you calculate PageRank using a relational database? As I said, with a graph database and Gremlin, you can do it in 2 lines.

For something on PageRank's scale, a custom datastore based on matrices and their multiplication makes business sense. Or MapReduce over a distributed key-value store (note that these are both OLAP approaches).

Still. SQL's a bit verbose, but these days we have recursive queries. For Oracle users, I'm talking about CONNECT BY. If I find myself running the social graph every minute, I develop an ETL package that periodically moves data from my write-bound system to my read-bound system with a more query-friendly schema. Depending on how you look on it, relational systems invented "eventual consistency".

More to the point, boring old database greybeards have learnt that OLTP and OLAP are very different use cases. The 3/4/5NF of the OLTP database will be very different from the star schema of the OLAP database.

There's really not much about NoSQL that hasn't already been done, under a different name, by the relational crowd.

I still think there is a place for NoSQL. It's just not as universal a replacement for relational systems as many make it out to be, whether we're talking about document stores, distributed key-value stores, graph stores and so on.

Despite a desire to use Postgres, we use MySQL in production. MySQL is what I knew and thus still what I know. Given that most future work involves an ORM, probably moving to postgres as soon as I learn more about configuring the server.

Currently using memcached (not memcachedb) for caching, thinking of trying out Redis.