Naming the DBMS disruptors
Edit: This post has largely been superseded by this more recent one defining mid-range relational DBMS.
I find myself defining a new product category – midrange OLTP/multipurpose DBMS. (Or just midrange DBMS for brevity.) Nothing earthshaking here; I’m simply referring to those products that:
- Match the OLTP DBMS state of the art of some point in the 1990s, and hence meet most application needs today.
- Are significantly more affordable (in license, maintenance, and/or administrative costs) than the top-end products from Oracle, Microsoft, and IBM.
Basically, these come in three groups.
- “Open source” – these are the first ones most people think of. MySQL leads the way – if 5.0 works as advertised. EnterpriseDB has a very interesting offering. PostgreSQL has some fans away from EnterpriseDB. And then there are Ingres, Firebird, and others, at various levels of open-source purity.
- “Standard editions” – Informix SE may have been the first DBMS to use the “Standard Edition” term, but Oracle, IBM, and Microsoft all have free or low-cost versions of their flagship DBMS. These are basically crippled versions of the lead products, conceived as entry-level products to fend off price competition.
- VAR-oriented – Progress OpenEdge and InterSystems Cache’ are the two biggies in this category. (Informix SE also used to be pretty big.) These are products that are great to leave running with a stable packaged application suite in a small enterprise, or with a single custom app in a large department. I’m visiting Progress on Monday and may have more to say after that.
Even that’s a far from complete list. For example, the Sybase iAnywhere core product used to be a great laptop/desktop/workgroup RDBMS, and Sybase makes periodic noises about recommitting to that market.
So should you care? Yes. Overall, there’s a swelling, rather classical, disruption story. And if you’re an enterprise looking to consolidate your DBMS suppliers, you would do well to use one of these midrange products as well as (if you even need it) one of the top-end OLTP RDBMS.
As for what these midrange DBMS are or can be used for – well, that’s a long list. But some of the broad categories are:
• Most web-facing apps.
• Most departmental apps.
• All the processing at a typical medium or small enterprise.
Of course, the details depend on the match between your application needs and particular products. As just one example — if you need non-tabular datatype support, such as XML or geospatial, over half the possibilities can be immediately thrown out.
Comments
8 Responses to “Naming the DBMS disruptors”
Leave a Reply
[…] All in all, the MySQL/SolidDB combo seems like a reasonable option in the midrange OLTP DBMS market. […]
Overall, I’m pleased to see acknowledgment for this group of DBMS providers.
There are two terms I think are misleading, however. Your category of “midrange DBMS” makes it sound like these are not scalable for the larger enterprise. Do you have reason to believe that Caché, for example, is not as scalable as SQL Server, or even DB2 or Oracle? Is the “midrange” adjective related to the market these vendors most often target (perhaps not wanting to compete with the big three) or is it related to the DBMS technology?
The other term that is fast becoming outdated, perhaps, is “VAR-oriented.” It might be more accurate to call them App Developer-oriented or some such. Progress and Caché might be gaining marketshare with the SaaS model, whether from what were once VARs or from end-customers.
Hi Dawn! Thanks for commenting!!
First of all, I stand by what I said in “midrange.” Indeed, my first name for the category was “cheap.” Now, I know there’s some doubt whether SQL*Server and Sybase should be in the top echelon or one level down itself. If I wanted to build a huge online reservations system, I’d pick Oracle or DB2 over either of them. But I also think I’d pick them over anything I’m calling “midrange” here.
As for the SaaS/VAR distinction — I’d be surprised to find SaaS was that big a fraction of their business YET, especially if we look as SaaS vendors who aren’t also traditional VAR partners.
Hi Curt – I figured that even though I’m not taking the time to write right now, I should still keep up on reading. I appreciate your information and perspective, even when I have a slightly different take on it.
Midrange: I think “cheap” was more accurate, although “frugal” or “big bang for the buck” would be more generous (also more accurate IMO). I think you do know that Cache’ will scale better than SQL Server, for example.
I don’t really know how Progress or Cache’ (or UniVerse from IBM, e.g.) compare to Oracle across the board. Would you happen to be able to name 2 ways in which Oracle scales better than Cache’, or in which you suspect it does? My impression from anecdotes, along with what Intersystems says in their testimonials and product goals, indicates that Cache’ scales better than Oracle in at least some respects. So I am wondering where it falls down (into your “midrange” rather than “high end” category).
VAR: You are correct in that many software companies that write application software today would classify as “VARs”, but if you are coming up with designations for such products, I don’t think it is good to marry any databases to the VAR model when the SaaS model is coming on somewhat rapidly. I know of at least one company about to work on an SaaS with a database product that would end up in your VAR category.
So, for the DBMS products of most interest to me (those not constrained by the limits of SQL, for example) that would fit your categories of midrange and VAR-oriented, I don’t like either term as proper positioning for these products. I’m not fond of the positioning of some of these as “embedded” databases either, given that they often run ERP solutions.
I have thought about labels for such products, but have not come up with any that would be accepted by the majority either, but thought I would at least mention that the two terms above don’t resonate with me, someone who uses products in your “midrange” and “VAR-oriented” categories.
[…] should FileMaker be included on my list of midrange OLTP DBMS or not? • • […]
I’d say putting Cache here is a joke.
MUMPS hierarchical dbms, that’s what it is.
Raw performance of mumps inserts is good.
But tirggers integrity and the last moment I’ve seen
it optimizer are a joke. I most definetly it doesn’t
deserve being mentioned on par with any other dbms on this page
Some pretty serious OLTP database apps have been built in Cache’.
It’s not relational — at least, it’s not particularly good relational — and you lose that way. But it’s solidly OO, and that gives you some major offsetting gains.
Truth be told, I haven’t been briefed all that recently, nor talked with users, so I don’t know how far they’ve come in fixing their relational deficiencies. Last I looked, Cache’s relational functionality was best-suited for lightweight reporting.
But I don’t think that all serious OLTP DBMS have to be relational. There are good reasons why almost all are, but Cache’ is a legitimate exception to that tendency.
CAM
PS. Optimizers only matter for performance. If performance is good, simple-minded optimizers are OK. Besides, ALL optimizers are rather simple-minded …
[…] there you have it. Does FileMaker fit among midrange OLTP DBMS? Not in my taxonomy. But is it useful technology? Evidently, quite so. Categories: FileMaker, OLTP Subscribe […]