Reporter: [Care to comment]?
CAM: SQL Server is an adequate product if you don’t mind being locked into the Microsoft stack. For example, the ColumnStore feature is very partial, given that it can’t be updated; but Oracle doesn’t have columnar storage at all.

Reporter: Is the lock-in overall worse than IBM DB2, Oracle?
CAM: Microsoft locks you into an operating system, so yes.

Reporter: Is this release something larger Oracle or IBM shops could consider as a lower-cost alternative a co-habitation scenario, in the event they’re mulling whether to buy more Oracle or IBM licenses?
CAM: If they have a strong Microsoft-stack investment already, sure. Otherwise, why?

Reporter: [How about] just cost?
CAM: DB2 works just as well to keep Oracle honest as SQL Server does, and without a major operating system commitment. For analytic databases you want an analytic DBMS or appliance anyway.

Best is to have one major vendor of OTLP/general-purpose DBMS, a web DBMS, a DBMS for disposable projects (that may be the same as one of the first two), plus however many different analytic data stores you need to get the job done.

By “web DBMS” I mean MySQL, NewSQL, or NoSQL. Actually, you might need more than one product in that area.

Context for any comments on customer traction includes:

• Membase went into limited production release in October, and full release in January. Similar things are true of CouchDB.
• Hence, most sales of Couchbase’s products have been made over the past 6 months.
• Couchbase (the merged product) is at this point only in a pre-production developer’s release.
• Couchbase has both a direct sales force and a classic open-source “funnel”-based online selling model. Naturally, Couchbase’s understanding of what its customers are doing is more solid with respect to the direct sales base.
• Most of Couchbase’s revenue to date seems to have come from a limited number of big-ticket “lighthouse” accounts (as opposed to, say, the larger number of smaller deals that come in through the online funnel).

That said,

• Most Membase purchases are for new applications, as opposed to memcached migrations. However, customers are the kinds of companies that probably also are using memcached elsewhere.
• Most other Membase purchases are replacements for the Membase/MySQL combination. Bob says those are easy sales with short sales cycles.
• Pure memcached support is a small but non-zero business for Couchbase, and a fine source of upsell opportunities.
• In the pipeline but not so much yet in the customer base are SaaS vendors and the like who use and may want to replace traditional DBMS such as Oracle. Other than among those, Couchbase doesn’t compete much yet with Oracle et al.
• Pure CouchDB isn’t all that much of a business, at least relative to community size, as CouchDB is a single-server product commonly used by people who are content not to pay for support.

Membase sales are concentrated in five kinds of internet-centric companies, which in declining order are:

• Social gaming
• Ad platforms
• Online retail
• Online business, including B2B  SaaS
• Social networking

Bob said that Couchbase often sees MongoDB competitively, but never Riak, HBase, or Redis. I got the impression Couchbase sees at least a little Cassandra. That would, of course, all pertain only to direct sales, rather than download/community kinds of usage.

Couchbase is also excited about the potential for the CouchDB-based Couchbase Mobile occasionally-connected offering. The hottest use cases, interestingly, seem to be non-consumer; Bob rattled off military, farming, and health care, and surely could have named more besides. However, the Couchbase Mobile sales effort still seems to be in early days, as is evidenced by the fact that Couchbase has not yet competitively encountered Sybase SQL Anywhere.

With all that said, I’ll go now to a separate post for a Couchbase technical update.

1.  Oracle 11g Express Edition is seriously crippled. E.g., it’s limited to 1 GB of RAM and 11 GB of data. However …

2.  … I recall when I excitedly uncovered the first 1 GB relational databases, the way I’ve uncovered petabyte-scale databases in recent years. It was less than 20 years ago. This illustrates that …

3. … the Oracle 11g Express Edition crippleware is better than what top relational database users had 20 years ago. That in turn suggests …

4.  … there are plenty of businesses small enough to use Oracle 11g Express Edition for real work today.

5.  Sensible reasons for having an Oracle Express Edition start with test, development, and evaluation. But there’s also market seeding — if somebody uses it for whatever reason, then either the person, the organization, or both could at some point go on to be a real Oracle customer.

By the way, allowable database size of 11 GB is up from 4 GB a few years ago. That’s like treading water.

The first two things to understand about SQL Anywhere is that there actually are three products:

• Sybase SQL Anywhere, a mid-range relational DBMS.
• Sybase UltraLite, a DBMS for mobile devices.
• Sybase MobiLink, a replication/sync tool.

and also that there are three main deployment/use cases:

• Generic desktop or server computers. This was the original market for SQL Anywhere.
• Laptop/handheld computers. This was the original growth market for SQL Anywhere. In particular, Siebel Systems’ first growth spurt was selling sales force automation software on laptop computers with SQL Anywhere underneath.
• Specialized devices. Earlier this decade, Sybase thought SQL Anywhere’s big growth market was on specialized devices. (I recall a video featuring some kind of automated pill dispensing machine for hospitals.)

Meanwhile, terminological weirdness includes:

• At various times the product Sybase SQL Anywhere has had “Server” in its name, but that seems not be part of the naming convention at the moment. Sybase folks still talk about it that way, however.
• Is SQL Anywhere a product? A group of products? A division? Again, that depends on whom and when you ask.
• When Sybase speaks of SQL Anywhere being in the “embedded” database market, it’s talking of any OEM business, not just deployment on particular kinds of devices. (IDC has long used that confusing terminology, which is a regrettably good excuse for vendors to use it as well.)

I get the impression that there are two big markets for the Sybase SQL Anywhere family:

• ~1000 OEM partners for Sybase SQL Anywhere. Notable examples include:
  • Intuit (for QuickBooks)
  • Symantec (for NetBackup)
  • Sybase IQ, if you want to view it that way (a lot of Sybase IQ’s front-end is actually SQL Anywhere code)
• Direct enterprise customers for mobility-oriented combinations of Sybase UltraLite, Sybase SQL Anywhere, and Sybase MobiLink. Notable examples include:
  • Pepsi Bottling Group (repairmen, using handheld devices)
  • US 2010 Census (140,000 people address checkers – every address in the US was checked against GPS coordinates, it seems)

By way of contrast, the market for true embedded systems never took off as strongly for Sybase SQL Anywhere as it did for, say, pre-acquisition solidDB. Added together, this all seems to amount to ~ 10 million users overall, as per a slide deck Sybase graciously gave me permission to post.

Other market notes include:

• Sybase says that the main competitors for Sybase SQL Anywhere are Microsoft SQL Server, Oracle, and occasionally MySQL, with Progress coming up only rarely. I would have thought Progress OpenEdge RDBMS would be higher on the list (simple DBMS for the OEM market) – but come to think of it, it’s been quite a while since I’ve run into anybody who says they compete much with Progress OpenEdge. Perhaps Progress just isn’t selling its core product very hard these days.
• 80-90% of Sybase SQL Anywhere installations are on Windows, but the fact that SQL Anywhere also runs on Macintosh and ‘nix platforms is apparently pretty important to sales.
• The main platforms for Sybase UltraLite are Blackberry and Windows Mobile, although with iPhone support newly added in SQL Anywhere Version 12, that’s a good bet to change.

Besides the above, the key points about Sybase SQL Anywhere are:

• Sybase SQL Anywhere is designed for a no-DBA, “customers may not know there’s a DBMS” there kind of easy administration. (That’s one reason I compared it to Progress.)
• Sybase SQL Anywhere has a reasonable set of mid-range DBMS features, including:
  • Triggers
  • Stored procedures
  • Referential integrity
  • Geospatial datatype
  • Text datatype (with a CONTAINS clause), and you can index external documents
  • Multiprocessor/multicore operation

Sybase SQL Anywhere Version 12 seems to have a variety of performance improvements, of which the most interesting are:

• If you’re using an ORM (Object-Relational Mapping) layer such as Hibernate, the SQL Anywhere optimizer now works hard to rewrite some of the horrific SQL that can be generated, for example by flattening or eliminating a lot of subselects.
  • There’s also a “Hibernate dialect” of SQL Anywhere – I’m not sure what that means, but it clearly indicates that SQL Anywhere wants to be Hibernate-friendly.
• When the SQL Anywhere optimizer decides the statistics are wrong, it reruns them, piggybacking on a subsequent query if it can, doing a background job if it must. Somewhat pretentiously, Sybase refers to this as “self-healing statistics”.

Many SQL Anywhere features are of course missing in Sybase UltraLite, but geospatial datatypes are present.

Finally, it’s a natural conjecture that MobiLink is related to Sybase Replication Server – but that conjecture turns out to be wrong. That said, keeping Sybase’s various replication offerings straight is tricky.

That said,  

• Raj said that Sybase’s Aleri acquisition was, if anything, tracking ahead of expectations.
• Raj didn’t seem the slightest bit focused on the Coral8/Aleri CEP-based BI strategy that John Morell had long championed.
• Raj reminded me that Sybase SQL Anywhere has numerous OEMs, not just on the true desktop/laptop or smaller, but also in a return to its server/workgroup roots. Sybase SQL Anywhere even added geospatial indexing recently.

Raj also spoke glowingly of SAP’s in-memory database technology and the potential for Sybase of same — until I asked a follow-up question. At that point, he confessed that he didn’t really know much about about SAP’s in-memory database technology yet. As I said before, I believe SAP is fairly sincere about its belief that its in-memory database technology will conquer the world — but this is a naive and poorly-founded opinion even so.

One tidbit I did get is that SAP’s in-memory database technology is not just son-of-T-REX. A Korean (Raj thinks) company SAP had acquired is also in the mix. Raj also had the impression SAP’s in-memory technology can do rows, columns, or hybrid structures. On the one hand, that makes sense. On the other, it’s not a perfect fit with what Hasso Plattner said last year.

Nonetheless, OLTP/general-purpose data management startup activity has recently picked up, targeting what I see as some very real opportunities and needs. So as a jumping-off point for further writing, I thought it might be interesting to collect a few observations about the market in one place.  These include:

• Big-brand OLTP/general-purpose DBMS have more “stickiness” than analytic DBMS.
• By number, most of an enterprise’s OLTP/general-purpose databases are low-volume and low-value.
• Most interesting new OLTP/general-purpose data management products are either MySQL-based or NoSQL.
• It’s not yet clear whether MySQL will prevail over MySQL forks, or vice-versa, or whether they will co-exist.
• The era of silicon-centric relational DBMS is coming.
• The emphasis on scale-out and reducing the cost of joins spans the NoSQL and SQL-based worlds.
• Users’ instance on “free” could be a major problem for OLTP DBMS innovation.

I shall explain.

Big-brand OLTP/general-purpose DBMS have more “stickiness” than analytic DBMS.

• OLTP applications are more complex than analytic ones, and hence more tightly wired into particular brands of DBMS. For example, third-party packaged OLTP applications are typically portable among only a few brands of DBMS. But third-party business intelligence tools, and the BI “applications” built in them, are more easily and widely portable.
• Specific technical observations such as “OLTP apps tend to use stored procedures, which are DBMS-specific” or “OLTP apps tend to have lots and lots of tables” serve to underscore the first point.
• An enterprise’s highest-value data is commonly the financial stuff handled by its core OLTP systems, so those are the last things they want to mess around with just to get some cost savings. Security, high availability, and so on are major considerations that can outweigh cost.

By number, most of an enterprise’s OLTP/general-purpose databases are low-volume and low-value. Indeed, “OLTP” is often a misnomer, which is why I tend to go with “general-purpose” or some similarly wishy-washy phrase instead.

• In theory, this is a ripe area for what I’ve called mid-range DBMS.
• The big brand vendors try hard to keep as many of those databases for themselves as they can. Enterprise-wide license pricing helps. Going forward, so will virtualization/consolidation strategies, such as Oracle’s Exadata-centric approach.
• A variety of mid-range DBMS alternatives beyond the big brands have technical merit, at least in some cases and configurations – MySQL, PostgreSQL, Intersystems Cache’, and so on.
• The only such mid-range DBMS alternative with much large enterprise business momentum, however, appears to be MySQL.

“General-purpose” might be a better term than “OLTP” anyway.

• I don’t have a link, but it’s widely agreed that over half of the processing on an “OLTP” enterprise app is commonly reporting and so on.
• “Operational BI” is progressing by fits and starts, but it is progressing.
• Anything customer-facing — web-based, call center, or otherwise — is likely to include a heavy dose of “real-time” analytic optimization.

Most interesting new OLTP/general-purpose data management products are either MySQL-based or NoSQL.

• VoltDB is the main exception that jumps to mind.
• This isn’t true in the analytic DBMS area, where Netezza, Greenplum, Aster, Vertica and others started from PostgreSQL’s code, APIs, or both.

It’s not yet clear whether MySQL will prevail over MySQL forks, or vice-versa, or whether they will co-exist.

• MySQL is a limited product without all the third-party storage engines that are being developed.
• Oracle’s promise of MySQL good behavior has an expiration date.
• None of the MySQL front-end alternatives are remotely mature yet.

The era of silicon-centric relational DBMS is coming.

• I think “silicon” means “solid-state memory” as much as or more than it means “RAM,” but that’s not yet certain.
• What is pretty certain is that, thanks to Moore’s Law, some kind of silicon will increasingly replace disk.
• Oracle’s increasingly Flash-centric story is a challenge to everybody.
• RAM-centric VoltDB will launch fairly soon. (By the way, while VoltDB still has a lot in common with H-Store, they’re not exactly the same thing. And H-Store research is progressing too.)
• RethinkDB is being developed, focused directly on solid-state memory. Based on the sparse information available online, RethinkDB sounds somewhat like a dumbed-down H-Store.
• New disk-based vendors may never optimize their use of disk, instead targeting a solid-state future. (E.g., I think Akiban should and quite well might follow this path.)

The emphasis on scale-out and reducing the cost of joins spans the NoSQL and SQL-based worlds. We hear that from the NoSQL guys all the time. But I also just heard it from Akiban.

Users’ instance on “free” could be a major problem for OLTP DBMS innovation. Vendors of new OLTP data management technologies often feel obligated to open source their products, notwithstanding the historical lack of revenue in the open source OLTP DBMS market. As just one of many examples, Nova Spivack wrote:

I have recently seen some new graph data storage products that may provide the levels of scale and performance needed, but pricing has not been determined yet. In short, storage and retrieval of semantic graph datasets is a big unsolved challenge that is holding back the entire industry. We need federated database systems that can handle hundreds of billions to trillions of triples under high load conditions, in the cloud, on commodity hardware and open source software. Only then will it be affordable to make semantic applications and services at Web-scale.

I hear similar things from other startups, who evidently believe they need and/or are entitled to enjoy sophisticated, high-performance, zero-cost, specialized database management technology.

• MUMPS, the original Intersystems technology, was focused on health care.
• The reasons Intersystems went object-oriented have a lot to do with the structure of health-care records.
• Intersystems’ biggest and most visible ISVs are in the health-care area.
• Intersystems is actually beginning to sell an electronic health records system called TrakCare around the world (but not in the US, where it has lots of large competitive VARs).

Note: Intersystems Cache’ is sold mainly through VARs (Value-Added Resellers), aka ISVs/OEMs. I.e., it’s sold by people who write applications on top of it.

So far as I understand – and this is still pretty vague and apt to be partially erroneous – the Intersystems Cache’ technical story goes something like this:

• Intersystems Cache’ is an object-oriented DBMS.
• The preferred language for talking to Intersystems Cache’ is Java.
• Intersystems claims Cache’ has good SQL performance, for most kinds of use-case.
• Intersystems Cache’ stores data in a kind of sparse hierarchy. It uses a lot of “common character count” compression, which sounds a lot to me like Patricia tries.
• Intersystems has recently bundled some BI/reporting tools into the Cache’ stack. Surely not coincidentally, Intersystems once told me that some of its ISVs paid more to Crystal Reports than to Intersystems.
• Intersystems Cache’ has had Sybase emulation for several years, and just added Informix emulation. Most but not all stored procedures from those other DBMS run against Cache’ as well.
• Intersystems Cache’ recently added a bunch of manageability, security, etc. features, the details of which generally inspired “Oh, you didn’t have that earlier?” reactions in me.
• Intersystems’ just did a revamp of the Cache’ object model to make it more Smalltalk-like, in which messages are set to parent rather than child classes when appropriate. Thus, when you recompile a class, you don’t also have to recompile all its children, and incremental recompilation is now near-instantaneous. (Put that one in the “Oh, you didn’t have that earlier?” category too.) Versioning will be better as well.
• In the latest release, Cache’ has added what Intersystems calls “Java Event Processing.” This doesn’t sound like CEP (Complex Event Processing), and I forgot to ask whether it was memory-centric at all. Anyhow, the idea is to bang objects into the database really quickly, having them be immediately available for SQL query. “Really quickly” means >10,000 objects/core/second, with one test at the European Space Agency getting up to 85,000. By way of contrast, Intersystems asserts (based on bake-offs) that RDBMS competitors have to insert into BLOBs to get competitive performance, with associated loss of queryability.

Finally, a few financial highlights:

• Intersystems did a little over $1/4 billion in revenue in 2009.
• 85% of that was Cache’.
• Revenue growth was slightly positive in 2009, and 15% in 2008.
• Headcount growth was 25% in 2009 and is planned to be big again in 2010, after being modest in prior years.

]]> http://www.dbms2.com/2010/01/15/intersystems-cache-highlights/feed/ 5 http://www.dbms2.com/2009/09/10/what-could-or-should-make-oraclemysql-antitrust-concerns-go-away/ http://www.dbms2.com/2009/09/10/what-could-or-should-make-oraclemysql-antitrust-concerns-go-away/#comments Thu, 10 Sep 2009 14:53:23 +0000 Curt Monash http://www.dbms2.com/?p=879 When the Oracle/MySQL deal was first announced, I wrote:

I can probably come up with business practices that could make things very hard on Oracle/MySQL competitors … but I haven’t found a compelling antitrust trigger on my first pass over the subject.

Subsequently, there’s been a lot of discussion about whether or not Oracle can use control of MySQL to make life difficult for third-party MySQL storage engine vendors.

Now that the European Commission is delaying the Oracle/Sun deal, explicitly because of Oracle/MySQL antitrust fears.  That is, the European Commission wants to be reassured that an Oracle takeover of MySQL won’t unduly impinge upon the future availability of open source/low cost DBMS alternatives.  This raises that natural question:

What could Oracle do to assure concerned parties that its ownership of MySQL won’t unduly hamper open-source-based DBMS competition?

I think that’s indeed the crucial question. The Oracle/Sun deal has enough momentum at this point that it both should and will be allowed to happen — perhaps with safeguards — rather than banned outright. If  you have concerns about Oracle’s pending acquisition of MySQL, you should speak up and outline what kinds of regulatory safeguards would alleviate the problems you foresee.

More or less obvious possibilities include:

• Divest MySQL. This is obviously an extreme measure, but it surely would work.
• Provide some money and trademark rights to MySQL forkers. If MariaDB and Drizzle were put into strong competitive positions with MySQL today, it’s hard to argue how regulators could object to any future Oracle maneuverings Oracle might envision with the GPLed side of MySQL.
• Offer a standard, attractive, long-term deal to MySQL bundlers. The commercial/non-GPL version of MySQL is a requirement for appliance vendors (surely), OEM vendors (probably), and storage engine vendors (maybe — I disagree, but I’m evidently in the minority).
• Strengthen PostgreSQL. Realistically, that’s not going to be part of any Oracle/MySQL resolution, so I’ll leave it as a subject for another time.

• IBM is already serious about supporting multiple database management systems. DB2 on open systems is IBM’s flagship DBMS. But DB2 on mainframes and at least one flavor of Informix seem to be getting maintained and enhanced fairly seriously as well. And IBM has further DBMS products as well (e.g., DB/2 on the AS/400). There’s little reason to think IBM would orphan MySQL or any other DBMS product.
• IBM is very open-source-friendly. For a company that grew up for decades on proprietary software — and still is a huge software products vendor — IBM is very serious about open source. If you doubt that, I have two words for you: “Linux” and “Eclipse”.
• MySQL might finally get its industrial-strength act together. IBM is good at database management and good at open source. MySQL becoming a no-apologies transactional DBMS would obviously put pressure on Ingres, PostgreSQL, and EnterpriseDB, although there surely would be lots of happy talk about the open source DBMS market being validated, lifting all the vendors and so on. Also, a better MySQL could be bad news for Microsoft SQL Server too.
• Sun has a lot of DBMS partnerships right now. Obviously, Sun owns MySQL, and has partnerships with MySQL storage engine vendors such as Infobright and Kickfire. Sun also has a substantial partnership with Greenplum, and a Barneyesque* one with ParAccel. And of course Sun has strong working relationships with major database vendors such as Oracle and Sybase. What’s more, on a case-by-case basis, Sun may cooperate in the field with yet other DBMS sellers. E.g., I’ve confirmed at least one instance of a Sun sales rep recommending a Kognitio DBMS.
• IBM partners with outside DBMS vendors too. You’d think IBM’s gazillion DBMS product lines would be enough. But nooooo. I frequently hear rumblings of IBM’s hardware or services operations working with other DBMS products as well. (This is, of course, actually to their credit.)
• Short-term, there probably would be little effect on partnerships. Greenplum runs on Sun’s Thumper/Thor line of boxes. DB2 doesn’t, and certainly isn’t optimized for same. In the short term, to sell Thors, Sun would presumably continue to sell Greenplum.
• Longer-term, there could be a DBMS rationalization. DB2, Informix, MySQL + storage engines, and big independent vendors such as Oracle and Sybase would surely always get attention. That’s a lot. There might not be room for much mind share for many database products and vendors beyond that list.

*A Barney partnership is one in which two or more vendors get on stage and do a song and dance about how much they love each other, with little substance beyond that.

Related links

• Larry Dignan thinks the IBM/Sun deal is sensible and ripe to happen.
• Dana Gardner thinks otherwise.
• Matt Asay seems to agree that IBM understands the open source business.
• Before IBM acquired it, solidDB was scheduled to provide a serious MySQL transaction processing engine.

Before Solid and solidDB were acquired by IBM, one of the things Solid was proudest of was some embedded apps in which solidDB ran for years in boxes without keyboards or monitors.

I still think it’s a pity that IBM isn’t using solidDB as broadly as the technology deserves. Even so, this is a nice endorsement of MySQL for reliable zero-DBA mid-range use.