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 …

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.

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.

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.