April 2, 2009
Ingres update
I talked with Ingres today. Much of the call was fluff — open-source rah-rah, plus some numbers showing purported success, but so finely parsed as to be pretty meaningless. (To Ingres’ credit, they did offer to let me talk w/ their CFO, even if they offered no promises as to whether he’d offer any more substantive information.) Highlights included:
- Ingres is much of the way toward SQL 92 compatibility.
- Ingres also has added some industry-common proprietary SQL extensions. E.g., it appears multiple vendors have adopted Oracle’s way of doing substrings along with the standard way.
- Development chief Bill Maimone points out that when Ingres was still owned by CA, a lot of work was done to increase availability. (Arguably, Ingres’ main use at CA was as the underpinning for CA Unicenter.)
- I’m sure Ingres would disagree with this phrasing, but it sounds as if Ingres’ appliance strategy is more bait-and-switch than anything else. E.g., Ingres appliances don’t have the Red Hat version of Linux many users want.
- That said, Ingres’ BI appliance has enjoyed a “fair” number of small sales. Ingres claims — not unreasonably — that with a mature optimizer and parallel query, its product is suitable for at least lightweight reporting despite a lack of more advanced data warehousing features.
- Ingres does say, using the appliances as an example, that it built an installer much easier than what it had before.
- Although Ingres said something last August to Seth Grimes that sounded like it was going to integrate MonetDB, that’s not actually happening. Ingres does seem to have some kind of data warehousing speed-up project in the works, but was coy as to details.
- Ingres believes it will soon leapfrog closed-source vendors in its geospatial support, helped by significant community contributions. (Geospatial was the only part of Ingres it didn’t have the licensing rights to open-source, which is a bit part of the reason it’s being replaced.)
- However, it didn’t sound as if Ingres was doing much else in datatype extension.
- Speaking of data-warehousing-oriented enhancements, another example of nontrivial community contribution is partition-compatible hash aggregates.
- Another example is column encryption.
- Generally, Ingres echoes what other open source vendors say: The community will work on what it wants to work on, and many of the vendor’s priorities have to be implemented by the vendor itself.
- I didn’t ask directly, but I get the sense Ingres has concentrated some of it sales efforts in the financial industry, for three reasons. First, Ingres says it is doing a lot of Sybase replacements. Second, when Ingres said it hasn’t had as much success replacing Oracle, but has some hopes that this will change, it used financial companies as an example. Third, that’s the market Ingres used to say it was focusing on.
- Ingres says it also is doing OK in Microsoft replacements. But MySQL replacements are harder because MySQL is so non-standard that porting applications is more challenging.
- In another slap at MySQL, Ingres suggested that it’s hard to reference a BLOB in MySQL without pulling the whole thing down to the client.
- While conceding Postgres is good technology, Ingres asserted having a support organization is a competitive advantage. I asked a couple of times “What about EnterpriseDB?”, but didn’t get a response.
Categories: Actian and Ingres, Data warehousing, EnterpriseDB and Postgres Plus, MySQL, Open source, Oracle, PostgreSQL, Sybase
Subscribe to our complete feed!
Comments
6 Responses to “Ingres update”
Leave a Reply
It’s likely that any organization that wants to replace Oracle with an open-source DBMS would be better served going with PostgreSQL, which seems much closer to Oracle compatibility than Ingres is. I agree that EnterpriseDB and its Postgres distributions would cover most enterprise support needs.
I also have in my August 19, 2008 Ingres-conversation notes from TDWI-San Diego: “claim 5-6 western-area DWs in recent months.” It would be good to have confirmation from Ingres on the accuracy of that statement. Lastly, in my notes I see that the Ingres rep & I discussed Ingres’s lack of bit-mapped indexes or rollups (a SQL-99 feature), both of which are helpful in conventional data warehousing. (Some DW systems that have appeared in recent years of course don’t rely on indexes.)
Seth,
Actually, EnterpriseDB’s Postgres Plus is the one with particularly good Oracle compatibility.
Although if you’re using any datatype extensibility at all, any version of PostgreSQL is better than MySQL or Ingres.
Curt,
Does Ingres expect to migrate MySQL deployments because they have better BLOB support?
No, Mark, that’s a small example illustrating the difference between simulating support in a client driver versus full support in a server. Another would be scrolling cursors. You can do the feature wholly in the driver by pulling the full result set to the client, or you can support scrolling on the server which can reduce client-server activity. Curt asked for a list of everything wrong with MySQL, which I didn’t pursue. Actually I think MySQL has done a phenomenal job in particular with web content. And acknowledged to Curt, if there were no MySQL than probably there would be no reborn Ingres. MySQL made possible the category of open source database, and for that we all are appreciative.
On compatibility with Oracle, EDB certainly is better, considering it’s work on supporting PL/SQL. After quite some thought, I decided that for now the prospect of trying to do plug-compatible conversion of applications written in PL/SQL is not an attractive business. If it’s written to PL/SQL, than it has only ever run on Oracle and there are likely to be a long list of Oracle-isms. Conversion probably is a long project, and the longer the project the higher the chance of failure. There are so many applications written to run on more than one database. With always limited resource those applications are a better business for now. And believe me, I know lots about PL/SQL, having run the group for a half-dozen years. It was quite a challenge to keep one version of PL/SQL fully compatible with the next.
[…] Worst is when somebody insistently tries to “educate” me on something I already — often visibly — k…, or even disagree with. or perhaps just don’t care about. Unlike journalists, [influencers […]
We use Ingres and Oracle at our shop.
There were, at one time, plans to migrate away from Ingres, but the Open Source version and cheaper TCO has brought Ingres back in favour.
Oracle on the other hand has done itself no favours with its latest price hikes and we are looking very closely at migrating away to a cheaper solution.
The good news from our perspective is that we have always been shy of using lock-in features like PL/SQL, choosing to use Java instead. Performance isn’t as good, but hardware is realtively cheap these days and we have managed to keep out of Oracle’s Jail!
So where do we migrate to? That’s a very good question that hasn’t been resolved yet. My money’s on Ingres as we have a lot of expertise in the product and it can easily handle 90-95% of what our Oracle databases do at a fraction of the cost.