The database platform market is a $18.8b market that is largely dominated by 3 players, IBM, Oracle and Microsoft. Every year though we see new products come onto the market that claim to be the next big thing or offer significant benefits over the traditional big 3 RDBMS’s. Often that may be the case, but the problem facing every entrant is that the big three’s dominance is due to historical timing and leveraging opportunities that existed which no longer exist.

IBM has its place in the big 3 due to a 30 year history in the relational market, in fact as the original developer of the relational theory and the SQL language. However IBM has largely focused on its mainframe and mini computers over the last 30 years and its database revenue is largely tied to continued revenue streams from these core systems.

Oracle again has a 30 year history, they really developed and pushed along the advancements of the relational database platform and so quite rightly are the kings of the database revenue castle. And they build their customer base from a top down approach, focusing on the big end of town first filtering its products down from large mission critical core database servers, though to smaller and mid range requirements.

Microsoft on the other hand recognized an opportunity for entering the market by taking over the small end of the scale and working itself up. In the mid 1990’s, SQL Server was launched and the focus was on workgroup, mid range requirements – essentially a step up from their Access product. Due to Microsoft’s dominance at this level, the PC level, SQL Server rapidly expanded and as people gained confidence and expertise in the product, SQL Server slowly worked its way up into the enterprise over the last 14 years. However the other card that Microsoft carried was the high level of third party application developer engagement and support. Making it easy to build new SQL Server database applications, and the lack of a “cheap” easy to use mid range database platform alternative meant that third party developers in their droves started building their mid range apps to use SQL Server instead of (or as well as) Access or Oracle.

So the situation today is that IBM, Oracle and Microsoft have all come to the same point with Oracle in the middle and are competing head to head to make incremental gains in their respective market shares. Oracle and IBM are competing on the non Windows platforms, Oracle and Microsoft are competing on the Windows platform. The products themselves are largely equivalent, so the competitive advantage is no longer about core features, corporations are making decisions on what is their preferred platform based on cost of ownership, in house skills, and customer/vendor relationship quality.

But why is it so hard for another vendor to enter this market with something that is better, cheaper, faster etc? Well the database market has a chicken or the egg situation surrounding the applications that use the databases themselves. If you look at database applications that are focused on use in medium sized businesses and above, you can be 99% sure that they will support either Oracle or SQL Server or more likely, both. For database applications that only run on Windows, almost all support SQL Server, many support SQL Server and Oracle a subset just support Oracle. Even Oracles own applications (that it has acquired) for example, like JDE and Peoplesoft support using Oracle and SQL Server databases. The reason is that the third party application vendor doesn’t want to lose sales because their product doesn’t support the chosen database platforms of their potential customer. They know if they support SQL Server and Oracle they will be compatible with almost every customer opportunity they come across.

You may then ask why companies are “choosing” a database platform, shouldn’t they just implement whatever is the best (or cheapest) for the application requirement? Well to reduce TCO around the database platform companies have found that the only way you can really do this is to have a high level of standardization on one platform or another as this gets them better license deals and allows them to keep a single core skill-sets in house to manage those systems. Note, most companies don’t fully exclude any other database platforms completely, instead when performing a database application selection process, applications which don’t work with their “preferred platform(s)” are marked down, so in theory they could still win assuming they have significant other advantages over competitive products (in reality this is rare).

For a database application vendor to add support for multiple database platforms is a costly process. There is development effort, testing effort, ongoing testing of database patches etc and if supporting Oracle and SQL Server covers almost all potential sales, how do you justify such high additional costs for such a low return that will be achieved by support other database platforms?
So the chicken and the egg? As I mentioned the situation now is that few database application vendors are going to build a product for a database platform that a large number of potential customers aren’t using. The customer on the other hand isn’t going to choose to implement a database platform that most of their database applications don’t support.
Ok, so as a database platform vendor how do you enter this market then? Well there are a few ways.

1. You launch a product that is so compelling that customers start demanding their application vendors support it. Note, creating an equivalent product and making it “free” to date has failed to create this level of demand.
2. You launch a product that is so compelling that developers build their applications for it and then force their customers to install the platform.
3. You predict a future trend and get started in that future trend early before any of the main three do and create a level of dominance. Note, object databases as a future trend has a long trail of wreckage behind it. Clouds are interesting and BigTable & SimpleDB have gained some early dominance here.
4. You forget the corporate bread and butter database market for the time being and pick off a niche or two and focus on that. Clouds (currently a niche but may be the next big thing), In Memory DB’s, data warehouse appliances, rotated tables. All nichey nichey, but allows a new vendor to gain some sort of a foot hold. But it will have to be a very big niche if your foothold is going to leverage you into the corporate database market, and it will have to be a niche that you will have to maintain dominance in for 10 years or more (based on past history).

So #4 seems like the easiest way to enter the database market and make some money, but of course it can’t be that easy. As I mentioned, the big 3 are kind of in a stalemate situation in terms of gaining market share over each other so they are looking at other areas in which to gain ground, which of course includes this niche market (and there have been a lot of niche acquisitions by Microsoft and Oracle of late)!

I have been mulling over the Datallegro acquisition by Microsoft for the last week, mostly because I have been too busy to get my thoughts down.  Anyway, my analysis is that it’s a good attempt to claw some of Oracle’s dominance in terms of revenue in the DBMS market, but in itself is not a game changer.  Just another sign that core RDBMS functionality isn’t going to be what the battles of the next few years focus on, it is all the bolt on features that surround it that will decide who edges ahead and who lags behind. 

Certainly the model is now going after specialty markets one by one, none of them alone add up to a lot but get enough of them then you start to make a dent.  So expect the core RDBMS to be sliced and diced in different ways, specialty products to continue to be the focus, and new an interesting licensing models to flow that will make one vendors product more compelling to a market segment that another’s.

We have been discussing Sun’s acquisition of MySQL recently and common consensus was that we saw the key opportunity for MySQL was in the cloud, and hence an expectation that Sun would be announcing a Cloud MySQL offering sometime soon to start to justify their $1 billion investment.  That seems a somewhat more likely now that Suns director of architecture has gone public with his MySQL cloud project, codenamed Drizzle.

Essentially they are following the same starting strategy as the other early entries into this space (such as Microsofts SSDS).  Strip out all the stuff a relational database has that isn’t 100% necessary for basic CRUD operations (features that all carry some level of performance overhead) then focus on making the simplistic  shell that is left scale to address key cloud issues (very large data volumes, multi node partitioning, online provisioning, fault tolerance and redundancy etc).

While he has been clear in stating that this is not a “Sun/MySQL” product, I think this is just the unusual path that open source software follows and if it is successful eventually Sun will pick it up and start to offer a Cloud SaS offering (this project has apparently beenencouraged by Sun’s “upper management”). 

An interesting situation that I have noticed quite in recent times is that enterprise organisations looking to save on their database costs have been changing their preferred platform from Oracle, Sybase and DB2 not to Open Source but to SQL Server.  There are a number of reasons for this, but predominately:

• SQL Server has shown to require a significantly lower TCO than Oracle.
• Almost all vendors that create databases applications have an Oracle or SQL Server option. Application compatibility / availability will be one of the key criteria’s behind such a decision.
• The enterprise still has a large vendor behind the offering with account management and support escalation processes that can be engaged when really necessary.

At the moment, Microsoft has been providing a “best of both worlds” alternative to Open Source, which the enterprise has made the move to.  For example, most of the major banks in Australia have SQL Server as their preferred platform and only implement Oracle if there is no application compatibility with SQL Server.  If “SQL Server” wasn’t filling in this gap, it would be easy to see that MySQL or PostgreSQL in such a position.

But as we know, people are always looking for ways to save money.  So what will be interesting is what happens in 3 to 5 years when these enterprise sites look to reduce the TCO of their SQL Server database infrastructure.

I have just finished reviewing IDCs Database Management Vendor Share results for 2007 and thought I would highlight some of the interesting results:

Microsoft’s SQL Server growth rate dropped from 25% in 2006 to 14% in 2007.  That has got to be a big concern over at Microsoft.  This basically shows they are not gaining market share from IBM and Oracle, just maintaining their current position and growing pretty consistent with market growth.  This puts a lot of expectations on the shoulders of SQL Server 2008.

Oracle’s 11G release nothing in terms of Oracle gaining any market share from Microsoft or IBM.  Oracles share relative to its 2 main competitors stayed constant during 2006 and 2007 at 112%.  Again introducing major releases to maintain the status quo instead of gaining new ground has to be a concern for everyone.

MySQL continues to have very low revenues and the lowest growth rate of any of the niche products, with revenues growing at a mere 10%.  This is below market growth, but significantly below that of a niche product finding its feet.  This is one to watch for next year to start to assess Sun’s impact.

Despite Oracle and Microsoft holding much of the media limelight, DB2 keeps trucking along giving up no market share to any competitor in over 3 years.  DB2 has maintained a consistent market share of 21% during this time.

The top 90% of the database market seems to be pretty well sewn up and locked in with the 5 top vendors for the near future.  However the remaining 10% (a $1.9b market) is highly flexible and offers significant opportunity to niche vendors with niche products.  Of course the top 5 will also be looking to this area to gain market share as it currently appears fruitless in trying to gain this off the other 4 key vendors, so expect more focus, acquisitions and innovation in the areas outside core RDBMS services.

While SSDS doesn’t appear to have an immediate significant impact for the enterprise, the key thing to keep in mind is underneath the SSDS offering Microsoft is running SQL Server in a “grid” style architecture.  One would assume that the learning’s and technology Microsoft has developed in putting together the SSDS platform will flow through to the wider SQL Server product on a future release.  While there are no specific Grid capabilities in the upcoming SQL Server 2008 release, let’s hope that the long overdue, game leveling cloud enabling feature becomes a reality in the next release of SQL Server due 2010/2011.

In our recent discussions around the Cloud Database offerings, we have mentioned that many of these services have deprecated many of the traditional RDBMS functions such as user defined transactions and referential integrity.  Over several decades these have been considered critical, non debatable database features.  I can’t imagine someone implementing a database application in an enterprise 10 years ago that wasn’t ACID compliant, you would have been nailed by the DBA and laughed out of the client as being non-enterprise ready.

What is interesting about this is though is more recently, over the last 3-5 years I have noticed a strong shift in application development away from many of the core RDBMS principals.  More and more applications, while using a RDBMS platform that supports ACID fully, are using uncommitted isolation levels, not running statements in user defined transactions and not implementing DRI.

The key reason?  Performance (including scalability and concurrency).  The most visible issue with an application is one that performs poorly, and with modern day scalability requirements in terms of concurrent users and data volumes application developers are avoiding as many of the ACID requirements that impact performance as possible.  How many 300GB databases did we see 5 years ago?  Now 100GB is an average size departmental database. 

Justification is that system failures are relatively rare, application code is heavily tested (as to avoid data inconsistencies) and some small level of data loss or “corruption” is justifiable in wider scheme of increasing numbers of transactions processed.  Some applications even run batch jobs to “patch up” inconsistent data periodically.  And so, as I put my question to you, performance trumps everything?

The objective of this article is to help describe and then position “Databases in the Cloud” as a solution to issues being faced today, or as a method of driving new value that currently isn’t happening today.  I try to avoid specific technological or implementational discussions and focus on the bigger picture.  My background is in Database Management, Enterprise Software Development, SaaS and Web 2.0. application development.

Overview

A good place to start is with some definitions.  These may or may not be considered industry standard as a lot of these concepts are still under debate, however these are the definitions I will use throughout this article.

• Hosted Database Service – An industry standard database server that is made available as a hosted service by a service provider. You connect to a server using a proprietary protocol and control the data and schema contained within a database, however the operational management are is performed by the service provider.
• Database as a Service (DBaaS) – An evolution of the above with a key difference, the interface to the database is using a standard SOA protocol (SOAP, REST). Rather than connecting to the database using a proprietary client library directly over TCP, the application connects to the DBaaS using a standard protocol web services protocol and consumes the methods and properties exposed by the service, which are used to issues commands to access and modify the data contained within.
• Grid Computing – Grids refer to the infrastructure that can scale out on demand, distributes load between nodes, has inbuilt fault tolerance, and high levels of scalability through scale out. Grid nodes can often be easily provisioned without downtime and are commonly constructed from industry standard hardware. Clouds are typically built on Grids.
• Cloud Databases – DBaaS, combined with Grid Computing, combined with utility computing i.e. all physical infrastructure details abstracted, accessed using standard web service protocols. Typically Cloud Database services providers provide an abstracted (you access the address of the cloud, rather than a specific server), highly available service, with an unlimited scalability potential. Internally the cloud is built on a grid with fault tolerance, load balancing and data partitioning capabilities. The utility component allows each user to “pay” for the service based on utilization of the service.
• Data as a Service (DaaS) – A further evolution of the DBaaS with a different focus. DBaaS is focused on making the “repository” of data a service which is accessed by various applications. DaaS is implemented overtop of DBaaS to expose the data itself as a service. This is an important future concept which physically will be implemented in Cloud services.

Clouds vs Hosted RDBMS

For all the major Cloud Database services right now, there are significantly more differences than just the interface.  Most major Cloud Databases have a simple, discreet subset of standard RDBMS functionality.  Common RDBMS functions such as stored procedures, triggers, transactional consistency across tables, DRI, object level permissions are typically not available.  In addition, accessing the data using the standard SQL is not supported.  Instead a simplistic Create, Retrieve, Update and Delete (CRUD) query syntax is provided for accessing individual records and basic RDBMS SQL functions such as joins are typically not available.

In many cases a defined schema is not available instead an individual record or “entity” can take on its own schema, at this point in time most Cloud Databases are not RDBM’s.  They are much more closely aligned with Object databases.

Why Is This?

The focus of current cloud implementations has been on achieving the scalability and performance goals of the cloud, and to do this it has been necessary to deprecate features and functionality to ensure the scalability of the platform.

One of the main issues with providing a full relational implementation in a service model is that in a RDBM’s it is largely the responsibility of the developer/dba/architect to manage the resource impact of various commands and the follow on impact that occurs, such as concurrency, resource bottlenecking, etc.  If not managed properly it is possible for a certain queries on large data sets to impact all queries occurring on a server though high levels of resource contention.  Complex queries doing large sorts, aggregations, multi table joins can require large amounts of memory CPU and I/O to serve.  To manage performance in these scenarios DBAs have the power to index, optimize memory allocations, optimize data placements, profile and tune queries using indexing and so one (note this has nothing to do with the relational SQL model itself, just the practicalities of physically implementing it).

This doesn’t play out well in a model where for all intensive purposes, the infrastructure and physical location and layout of a database is invisible to the developer of the application.  The possibility of causing high levels of impact to other users of a shared platform is very undesirable to the service provider, as is the requirement to have the customer review and make decisions on the physical layout of the data on the physical infrastructure.

Instead the current approach of the Cloud Database services is to move to the “client side” much of the processing overhead of intensive operations such as joins, sorts, aggregations etc and only allow the issuing of discreet and much more predictable (from an impact perspective) row focused CRUD operations reducing the possibility that a single query can cause massive levels of impact to the shared platform.  Because of the scale of the Cloud Databases being offered (TB, PB, billions of rows etc) the impact of unpredictable processing would be a massive problem.

The reduced functionality is a key difference that allows Cloud databases to provide near linear, unrestricted scalability growth in a uniform manner.  How this plays out into the future remains to be seen.  There will be improvements made in this area as vendors find means to address such issues.  For example, it is not only conceivable that you will pay for usage, but you will also pay for the size of your database processing pipeline.  If you issue a query that causes a high level of impact but only have a small pipeline, they your query will take much longer to process than if you had purchased a much larger pipeline option.

Doesn’t this Limit Cloud Databases?

Yes.  Right now you cannot simply decide to unplug an existing application from an onsite RDBMS and plug it back into a cloud database.  Existing RDBMS applications will currently be incompatible with most Cloud Database offerings.  Use of current Cloud Database offerings must have the application code changed to utilize a cloud database.

What Other Issues Limit Cloud Databases?

There are a number of other reasons that use of Cloud Databases is going to be limited currently, and limited for some time to come.  These reasons include:

Latency

The response time between an application and a database server is key for application performance, and directly impacts productivity in a lot of industries.  Current day database applications typically measure response time is in ms, many of applications process hundreds or thousands of application requests a second.  For a database on a LAN near an application latency is less of an issue, but for a Database Cloud hosted remotely, latency is a key problem that will mandate application architecture and limit Cloud usage. 
In such a situation, regardless of how good your ISP is, you are not going to have the same bandwidth available to you as you currently do on a 1GB switched backend server network.  Once you go out to the web your request is passing through firewalls, routers, multiple providers, then to the Cloud Database provide itself and back again.  This will be hundreds if not thousands of times slower than what is possible having your database server sitting next to your application server.

Security

Putting your data out there in a Cloud somewhere obviously has many security concerns that goes with it.  Security concerns around who in the service provider has access to the data, concerns around the robustness of the service providers security model, concerns around the transportation security model.

Availability

The availability of the Cloud will typically be very good, however if the Cloud is external the availability of the network and all the components between you and the Cloud provider must be considered.  You will likely pass through a bunch of ISPs, dozens of routers, firewalls, switches etc.  While your Cloud provider will likely provide you a service level commitment, you may not be getting the same level of commitment from your ISP.

So why use Cloud Databases Then?

If the major draw card for Cloud Databases was simply the ability for organisations to outsource their infrastructure requirements, then you would be quite right in concluding that hosted infrastructure services have been around for many years and have only made a minor impact, mostly in the SME market.  So what is it with Cloud Databases that is making them an area of great interest? 

Clouds for Web 2.0.

Clouds for Web 2.0. applications fit well for a couple of reasons.  Firstly, scale.  Clouds provide the promise or near unlimited scalability, so as a creator of such a service, if your service takes off then your Cloud Database service should be able to cope for your application to grow to hundreds, then millions of users.
Implementing such scalability internally is now much harder than it used to be because of the speed of internet growth, your application can literally go ballistic overnight.  Implementing increased infrastructure in response to customer demand in near real time, is a difficult and costly and worrisome area for most start ups.  We all know what can happen if you get it wrong, such as the recent very public issues that Twitter has been having.

Secondly cost to entry.  To implement a large scale robust “Cloud style” infrastructure in house is going to require some very high levels of expertise and a lot of capital.  For a start up on a shoe string, investing in database infrastructure to support 1 million concurrent users when you currently have 5 concurrent users is very difficult to justify.  Using a Cloud Database service allows you to pay for what you are using and then scale up your service quickly as your business takes off.

Of course a Database Cloud is only one layer in the application architecture so scalability issues surrounding other layers also need to be addressed in your architecture.

Don’t Cloud yourself Into a Corner

My biggest concern around Cloud offerings for Web 2.0. at present is ensuring you don’t cloud yourself into a corner.  What I mean by this is while Cloud offerings may meet your immediate application requirements, try and have some forward thinking about ways in which you will derive value from your data once you have amassed lots of it.  Aggregating data, analyzing data, doing things like data mining (to provide recommendations, up-sell etc) will later on become areas that you will be wanting to explore to provide more smart functionality back to your users.  Make sure the Cloud Database service you go with has the ability to allow you to leverage your data appropriate in the future else you will find yourself running into a brick wall in terms of your value cycle.

Clouds for the Enterprises

Clouds for the Enterprise are interesting as there is no specific reason why a Cloud cannot exist within the walls of the enterprise, a sort of corporate Database Cloud for internal use.  From an enterprise perspective, this is really combining Grid computing with DBaaS to provide a platform which enterprise applications can hook into and be free on any specific scalability concerns. 

External Clouds

External Clouds is what most people are referring to when the discuss Cloud Databases in an enterprise context.  Obviously Cloud Databases right now are not a replacement for business critical databases servers in such an environment.  The latency, security and network availability issues ensure that is not practical.  So why then would a corporate consider a Cloud Database offering?
Many enterprises have requirements to interact with external users and systems through applications and integration processes (edge computing).  Whether it be a web site, web store or b2b integration process, some level of data often needs to stray outside of a enterprise walls.  In these scenarios hooking into a robust cloud service may be preferable to placing corporate assets outside the firewall.

Summary

On reviewing this article I have found the following points that require further thought, investigation and elaboration:

• Cloud Databases for Web 2.0. / web based start ups are an attractive option as they allow for rapid growth and low cost to entry. However what are the barriers if you go down this path in terms of ability to derive value from your data assets.
• The Cloud Database scalability requirements are met by deprecating most core RDBMS functionality, functionality which has been seen as critical in terms of a RDBMS and built up over the last 30 years. So what is the true impact of this?
• Cloud Databases for Enterprise are interesting when you bring the Cloud internal, but have a weak positioning when talking about external Clouds. Most of the talk about Clouds for enterprise refers to external services, so their attraction seems understandably low. Edge computing and b2b use generates little excitement in me, so really I want to investigate this area further to see if there is a stronger potential here.
• The benefit of adding the SOAP/REST interface isn’t really explained in any detail in this article. Yeah it is a generic protocol that allows varied platforms to interact with the Cloud service, but there hasn’t really been an issue with all major application platforms having access to SQL Server, Oracle, DB2 or MySQL servers in the past. So what else is the value that this is providing?

So it is clear there is a need to delve into a lot of these areas in much more detail.  Many of the benefits of this model will become more solid as we start to describe more of the concepts surrounding DaaS, Data as a Service and start to position real solutions in response to real problems being faced today.

I am not against Open Source at all so I don’t want this to become a debate about that.  But a commenter saying that Open Source business models are well understood is not correct on this scale in the RDBMS market.  In large multi national RDBMS players such as IBM, Oracle, Microsoft we have seen free/Open Source software offered as teasers that lead into purchase software.  We have not seen an Open Source offering as a primary offering.

The economics of what Sun has done is interesting.  It has paid $1 billion for MySQL.  But remember, MySQL’s revenue is largely services* based, not intellectual property based, which means each and every sale they make they have all their standard delivery overheads.  In all service based organisations I have been involved, a 20-30% profit margin is considered normal.  So if everything stayed the same, it could take Sun an estimated 41 years to get their money back based on MySQL’s current revenue.

But this doesn’t take into account reinvestment into R&D.  For MySQL to not only grow, but simply maintain its market share they are going to have to invest heavily into expanding MySQL’s capabilities.  So assuming they are making standard returns on their services, this doesn’t leave a very large bucket to pipe back into R&D at the current time.  So when does Sun start getting payback on their $1b?

One would expected then that Sun believe they can increase MySQL revenues significantly.  Very significantly.  How they plan to do this is the unanswered question at the moment.  Obviously the cross sell opportunities will add a lot to the bottom line, but with the numbers we are talking one would hope they had a revelation, if not a revolution, up their sleeve.
 
* I think MySQL does sell some management products for MySQL that are not services based

I don’t think Oracle is going to be kicking themselves too hard here.  From memory in October 2005 Oracle announced it had acquired InnoDB (the most popular transaction storage engine for MySQL).  In late January 2006 Marten Mickos confirmed that Oracle had made a bid for MySQL which was not accepted, although didn’t state exactly when this occurred.  And a few weeks later in Feb 2006 Oracle announced it had acquired BerkleyDB, the other popular transactional storage engine for MySQL.

One view could be that Oracle tried to acquire MySQL, and when it failed it picked up the key dependencies of MySQL that MySQL itself didn’t control.  Another view might be that Oracle had a strategy to acquire all the pieces of the MySQL stack and failed to acquire the central piece, MySQL itself.

So for suspected pocket change compared with the $1 billion that Sun paid, Oracle still very much has a significant hand in the MySQL pie.  While InnoDB is GPL, so in theory it can be forked and developed outside of Oracle’s control, Oracle owns the innovation centre for InnoDB so this is unlikely to happen unless Oracle dumps it (which itself is unlikely, more probable Oracle will continue to develop it to maintain it’s position but I wouldn’t expect major new features to appear in InnoDB ahead of Oracle’s own products though).

Ultimately I don’t think Oracle believes in the MySQL business model enough to pay the price they were asking (I think they saw MySQL as a trajectory offering rather than a direct source of strong revenue growth).  Clearly Jonathan Schwartz has different ideas, but with MySQL revenues of only $70-80 million (0.4% of the $18.8 billion RDBMS market) that also remains to be seen.

What also remains to be seen is how MySQL’s business model flies in a Sun, a public company that has to be concerned about things like revenue, targets, profits etc.  If I make one of my products better (fix bugs, easy usability, ease integration) that means I will sell more and increase revenue. How will enterprise view building a dependency on a product whose revenue stream is fully tied to a paid support?  Dismiss the concerns as much as you like; it just seems like common sense that making such a product more robust, more usable, more reliable has to be somewhat counterproductive to the vendor.  I don’t want to start a whole debate around Open Source business models, but there is no one else doing this today in any sort of scale in the RDBMS market (IBM, Oracle and Microsoft’s free offerings are more entry point teasers) so it is another area of wait and see.

Anyway it is all very incestuous.  Sun owes a lot to Oracle, but in their apparent move to gain some independence from Oracle (Schwartz had reportedly stated for a while that they wanted to fill their gap in the database market) they have acquired a product which currently has a dependency on Oracle.  Stay tuned because who can predict how all of this will pan out!