Database management system choices — mid-range-relational
This is the fourth of a five-part series on database management system choices. For the first post in the series, please click here.
The other threat to the high-end relational DBMS vendors aims squarely at the heart of their business. It’s the mid-range relational database management systems, which are doing an ever-larger fraction of what their high-end cousins can. That said, different products do different things well. So if you’re not blindly paying up for the security of an all-things-to-all-people high-end DBMS, there are a number of factors you might want to consider.
- Need for attention. High-end OLTP DBMS generally need a lot of DBA attention. Mid-range products generally need less, sometimes a lot less. Most are newer or less-featured than the leading high-end products; either way, they’re apt to be simpler. And some are specifically designed to be used in OEM or embedded situations where DBAs may not be available.
- Administrative tools. The flip side of administrative ease is administrative tools. Here the high-end products are generally ahead of the mid-range ones, and different mid-range products have different available tool sets. Part of Microsoft’s initial success in DBMS was due to better tools, thanks to their PC-oriented usability labs. Oracle later hired away Borland’s usability guru Dan Rosenberg, who helped narrow the gap.
- Performance for the feature set you’ll use. Most relational OLTP DBMS have similar performance for simple applications running on single processors. But not every feature of every DBMS is equally well-tuned. Declarative referential integrity, replication, etc. can show considerable performance variations, especially among less-established products. And that’s just for tabular data. If you look at non-tabular datatypes, performance can vary greatly.
- Scalability. While single-processor performance is pretty comparable among OLTP DBMS, scalability is whole different matter. Some struggle at 8 cores. Others go much higher.
- Price and license terms. PostgreSQL and MySQL can be had for free. Edit: Ditto Postgres Plus. (At least for licenses; support is another matter.) Alternate versions of both cost money, but are much less expensive than, say, Oracle – unless, of course, your enterprise already has an all-you-can-eat enterprise license. License and maintenance costs vary widely among DBMS products, and also vary greatly for the same products among different enterprises.
We’ve recently had some lively discussions of mid-range database management systems. Rather than try to recapitulate them, I’ll just link you back.
- The case for mid-range DBMS.
- The case against mid-range DBMS. This one generated a lot of flames.
- A call for application examples that might clarify (or invalidate) my mid-range/high-end distinction. The replies were interesting, both for what they did include and what they didn’t.
The complete series
- Part 1: Database management system choices – overview
- Part 2: Database management system choices – 4 categories of relational
- Part 3: Database management system choices – relational data warehouse
- Part 4: Database management system choices – mid-range-relational
- Part 5: Database management system choices – beyond relational
Comments
3 Responses to “Database management system choices — mid-range-relational”
Leave a Reply
EnterpriseDB (as you know) is a very good example of this kind of product. EnterpriseDB is to Oracle as JBoss is to WebLogic Server, very approximately. It sounds like a great business model.
Very good example indeed. I named the category while planning a webcast I was doing with EnterpriseDB’s sponsorship.
CAM
[…] have in the past also advocated for a mid-range — i.e. lighter-weight — general purpose […]