Positioning your Database Start Up for Enterprise OLTP

It is important to realize that there is less diversity in the enterprise OLTP market than at any point in the last 20 years. Essentially this market has been boiled down to Oracle, SQL Server & DB2 (with few isolated exceptions). Most new deployments are typically using one of the first two options. The lack of diversity has created a stalemate or chicken & egg situation. Enterprises now only want to install new applications that have been built to support Oracle or SQL Server. This is what most of the enterprise application software vendors are supporting, so it gives them the ability to standardize their database platform across the enterprise. And of course, this means that enterprise application software vendors largely now only want to invest in supporting these two platforms.

Any new vendor coming into this market will find themselves stuck between the proverbial rock & hard-place. Enterprises don’t want your new database platform because it violates their standards and few applications are supported on it, and enterprise application software vendors don’t want to invest in developing applications for your database platform as their enterprise …

If you are pre-funding then you might find a focus on the enterprise hurts you rather than helps you. While almost all of the database revenues are generated by the enterprise, the VC perspective seems to be that the enterprise sector is flooded and enterprises aren’t buying right now.

So what can you do?

#1 Launch a database platform that is so compelling that enterprise customers start demanding their application vendors support it.

This is a tough strategy. Normally the enterprise does not demand vendors create applications for anything other than the main set of enterprise database platforms (Oracle or SQL Server and in more isolated cases for DB2 and MySQL). Usually they are satisfied with a choice of these.

For this to be of any success, what you are offering the customers has to be compelling, very compelling. MySQL being free, for example, has not been compelling enough for many enterprise customers to demand it or enterprise application vendors to support it (I am talking about pure enterprise OLTP here. This is not necessarily the case in other markets), unless combined with large volume deployment (see next point).

#2 Launch a database platform that is so compelling that application developers support it and then push their customers to install it

Again, doing in this in a broad way is going to prove to be very difficult. You need to win the enterprise application software vendors over in such a big way that they are:

Willing to invest development costs into supporting your database platform
Take the hit from the customers who won’t buy their product because they are not supporting the mainstream platforms
Spend a lot of time convincing their customers of the merits of your database platform

For this to happen you have to sell the enterprise application software vendors something they can’t do (or can’t do easily) on a traditional platform. It is not enough to be as good as Oracle or SQL Server for these application vendors. You need to create new opportunities for them that will help them win more business. Some reasons why a development organization may decide to invest in your platform include:

Much shorter development timeframes via less code to write etc. If you are a true RDBMS this is unlikely, but if you have a revolutionary interface you may have something here.
Much lower per unit license or manageability costs. This is relevant for high volume deployments (embedded, POS, mobile workforce) databases. Enterprises will also care less if the data is ultimately consolidated into a data mart on their preferred platform.

#3 Pick a high value niche and focus on fixing its problems

The “enterprise” is of course a generic term which describes most large corporate businesses, however within this market you will find specialist sub-markets. Telecom, mining, utilities, banks, financial markets etc. If you can focus on a more specialist market and build a database platform product specifically targeted towards that market you may be able to gain the elusive “specialty vendor” gate pass into those relevant enterprises. Again this is not something that can be done easily. It will only work if the generic solution is leaving them exposed in some way, and your specialist solution doesn’t bring with along its own insurmountable weaknesses.

MySQL Cluster is an example of a database platform product which has had some success at this. MySQL Cluster started as a solution for the telecom industry. It was focused on a specific niche and set about solving the “carrier grade” requirements of this market. It was successful in this niche and because of that it is being pushed out further in those organizations. While this is just a small niche, it has provided MySQL a foot in the door to the enterprise.

#4 Provide platform compatibility

The final way in which you can sell into the Enterprise OLTP market is by providing a compatible platform either cheaper or more scalable.

This is also a difficult sell but you have two sub markets here. Firstly, your customers in this space are enterprises which have developed their own apps. You can try and convince them to take their existing skills, knowledge and investment and switch out their existing database platform for yours. As they support the applications doing so means they can implement any workarounds if your compatibility isn’t 100% true.

You second sub market is to sell your benefits to the application vendors themselves. Your objective here is to get those application vendors to officially support your platform. Doing so then allows the enterprise to considering switching out their existing database platform for yours. If you don’t have the application vendor support then don’t even bother pushing this route. It is very unlikely that an enterprise will move a production application to a stack that their vendor doesn’t officially support, no matter how much better your platform is.

To get the enterprise application software vendors onboard enough to officially support your platform, you need to convince them that they are losing sales of their applications due to limitations of their supported database platform (which you of course mitigate). Perhaps this is due to very high license costs, poor performance or limited scalability. If you are providing good compatibility and you are really solving some of these issues, the application vendor has a low risk but high reward proposition in front of them. This may just be enough for them to stick their neck out and officially support your database platform.

EnterpriseDB’s Postgres Plus is an example of this. One of their main pushes is their Oracle compatibility & significant savings over pure Oracle license.

If you can also bring additional benefit to the party (increased performance/scalability is always good) then this will provide you added benefit.

For any of the above to be successful you need to ensure you are supporting the development stack with appropriate interface libraries for all the common development platforms (.NET, JAVA etc). Getting any third party tool vendors to support your database platform is highly unlikely at this stage of your lifecycle, so you will need to ensure you ship with basic tools for manageability and ad-hoc data. Performance profiling tools are also a must for any vendor targeting high workload customers.

Strategies that Won’t Work

Of course there are strategies that you should be aware of that won’t work. Common ones attempted include the following.

#1 Just being Cheap

Free is good right? Enterprise is trying to save money, right? So the enterprise is more likely to choose a database platform that is free than one they have to pay for, right? Well, no. Not really.

Cost of ownership is what it is all about and this is made up of a lot more than just license costs. Operational management, hardware, resourcing, training all contribute to the costs associated with running a large enterprise database environment. To minimize these costs enterprises like to have consistency and standards across their environment. This means minimizing the number of platforms, selecting the platforms goes back to what applications are supported on what platforms.

If you are not compatible but are cheap, the cost of migrating existing applications to your platform must be considered. You may be calculate your license costs may be $250k cheaper for enterprise X than the equivalent SQL Server licenses for example. However $250k doesn’t go far if they have to invest in the re-development & re-testing of their software applications to work on your platform.

One of the exceptions to this is when your platform is being deployed in large volumes (such as in POS or mobile scenarios).

#2 Just being Faster

We are 100 times faster than Oracle, so you should use us rather than Oracle. Right? Again, not really.

Being faster is good but on your own it is not enough to win you entry into the enterprise OLTP market. If you don’t have any existing platform compatibility, you could very well be the fastest database that no application uses. Unless you are using a strategy above AND being faster is part of that strategy (a great part of that strategy btw) then being faster is not of significant relevance to the enterprise.

There are loads of databases that are faster than SQL Server & Oracle for various workloads that aren’t used in the enterprise in any significant way. Don’t get me wrong. Fast is good. But being fast on its own is not a strategy for enterprise OLTP. You need to use your fastness as part of your strategy, but also make sure you are pushing all the other right buttons necessary to see your database platform climb get a finger hold in the immense enterprise database platform market.

Link to original postInnovations in information management