Netezza’s version of EnterpriseDB-based Oracle compatibility
EnterpriseDB has some deplorable business practices (my stories of being screwed by EnterpriseDB have been met by “Well, you’re hardly the only one”). But a couple of more successful DBMS vendors have happily partnered with EnterpriseDB even so, to help pick off Oracle users. IBM’s approach was in the vein of an EnterpriseDB–infused version of SQL handling within DB2.* Netezza just announced an EnterpriseDB-based Netezza Migrator that is rather different.
*The comment threads are the most informative parts of those posts.
I’m a little unclear as to the Netezza Migrator details, not least because Netezza folks don’t seem to care too much about Netezza Migrator themselves. That said, the core ideas of Netezza Migrator are:
- Netezza Migrator is an enhanced (?) version of EnterpriseDB’s Postgres Plus Advanced Server DBMS. (Recall that Postgres Plus is PostgreSQL-based and fairly Oracle-compatible.)
- Netezza Migrator does not run on Netezza appliances, but rather on conventional computers off to the side.
- Netezza Migrator generally farms out queries to Netezza appliances, but can also manage data itself. (That latter part could supposedly come in handy for small tables one might want to execute stored procedures against.)
- Netezza Migrator does a better job of farming out queries (and also inserts/updates/loads) to Netezza appliances than an Oracle DBMS would. The two biggest examples of that are:
- Oracle will farm out SELECTs, but not JOINs.
- Oracle won’t invoke Netezza’s parallel/bulk load capabilities.
Comments
19 Responses to “Netezza’s version of EnterpriseDB-based Oracle compatibility”
Leave a Reply
“EnterpriseDB has some deplorable business practices” – I could not find any examples of these stories. Could you elaborate?
EnterpriseDB walks out on contracts. Sign a contract, and there’s no assurance they’ll honor it. Actually do work for them, and there’s no assurance of getting paid. This is not just my own experience I’m referring to, although I have not secured permission to give details on any other example.
Meanwhile, I had one user client who bought software from EnterpriseDB — they quickly gave it back in disappointment. That one, however, was not obviously tied to any business practice shadier than the widely common sales tendency to accentuate the positive, gloss over the negative, and create some misleading impressions as a result.
There also is a lot of disappointment with EnterpriseDB in areas like product delivery and so on. Again, that kind of thing can happen even to more honest companies. But it all doesn’t mix well with EnterpriseDB’s overall approach to doing business.
Is it works like a wrapper? And what about the data migration from Oracle? Don’t think the EnterpriseDB’s Advanced Server is addressing it efficiently. The data migration seems to be a big challenge when it comes to migrating terabytes. Remember trying them at our telco project, EnterpriseDB product has shown a poor performance, our own scripts did a better job.
Just guessing here, Todd, but there should be a way to migrate straight to Netezza what’s going to Netezza, then give the metadata to EnterpriseDB-based Netezza Migrator.
Anyhow, a one-shot migration of some numbers of terabytes shouldn’t be a deal-breaker even if it’s slow. If you’re doing TB/day, of course, then performance matters a lot.
Nobody thinks this is a shiny panacea. Indeed, I know at least one Netezza competitor that was pitched by EnterpriseDB on a similar deal and said “Naah, we don’t see the point.”
@Todd,
I can’t speak for other products of course, but data migration is indeed a challenge for big OLTP systems. Perhaps that’s not as relevant to a warehouse though.
Our own migration tooling can do multi-terabytes a day, but that can still get tight with respect to permissable outage time.
Ideally the effective outage of a re-platforming should not take longer than the outage of an Oracle full version upgrade.
Tools that do change-data-capture come at play at that point.
So you migrate the data from a backup and then capture then rollforward the Oracle logs onto the target system (DB2 in our case) using regular DML.
Once the target is caught up you can stop Oracle, do final housekeeping (switch on triggers and RI) and flip the apps.
@Curt
I’m surprised that Netezza didn’t upgrade its Postgress version. That would have saved them the two-stage engine. Smells like a V2 in the waiting here.
Cheers
Serge
SQL Architect DB2 for LUW
@Serge,
What do you mean? Netezza forked from PostgreSQL from Day One. E.g., as per my other post, the Netezza optimizer isn’t PostgreSQL-based at all.
Best,
CAM
@Curt – Thanks. I was interested in you comment not from a sales perspective (we all know to take sales info with a grain of salt), but because I know there are a few respected PostgreSQL committers involved with EnterpriseDB. I would be disappointed if the company’s practices wound up casting a shadow over the PostgreSQL project itself.
@Matt,
I’d say EnterpriseDB’s business ineptness, over a couple of management teams, blew a wonderful window of opportunity to mainstream PostgreSQL. EnterpriseDB’s shady behavior is just one little piece of that.
Most times I mention the idea to a vendor client of doing something with PostgreSQL, their reaction is vehemently negative. That then turns out to be a reaction to EnterpriseDB rather than PostgreSQL itself — but for partnering/commercialization purposes, EnterpriseDB is the only game in town.
@Serge
All these are “Ideally” as you said. Many times we need to do it over and over again. A simple human error can be just a one reason. “Multi-terabytes” a day – please be more specific on how many 2 terabytes or 20 terabytes per day as it is a big difference, from Oracle in particular
@Curt On only game in town, what about Sun and Pervasive Software’s own PostgreSQL ? They do support it. Also Greenplum is by the fact a Postgre as well
@Todd,
Not enough oomph to turn it into a commercial success. And Greenplum isn’t selling PostgreSQL at all, just a PostgreSQL-derived product (as, to various extents, are a bunch of other analytic DBMS vendors, most notably Aster Data).
Facilitating smooth migration from Oracle to Netezza TwinFin: what’s not to like about that? This product removes a barrier to TwinFin adoption. It makes Netezza’s price performance advantages over Oracle even more attractive. Netezza is right behind this one…for obvious reasons. In my book, good relationships are measured in revenue not platitudes and I think our relationship with EnterpriseDB will prove to be a hit.
You can read our official party line at Phil Francisco’s blog on Netezza’s website.
@Curt:
I can’t (as in not allowed to) dwell deeper into what I think is possible here.
@Todd:
Our own free tool that does the migration can do low/multiple TB a day (keep in mind that mileage varies depending on IO subsystem and network bandwidth).
I don’t know what the throughput of an true ETL (for $$).
I’m confues why you woudl do this multiple times.
The enabling itself is typically done on small test system. Moving the production data is a one time thing.
Cheers
Serge
@Tim,
It would have been wholly acceptable to actually include a link to the post you referred to, namely http://www.enzeecommunity.com/blogs/nzblog/2010/06/27/netezza-migrator-a-point-of-clarification 😉
[…] How Netezza Migrator works […]
“Most times I mention the idea to a vendor client of doing something with PostgreSQL, their reaction is vehemently negative. That then turns out to be a reaction to EnterpriseDB rather than PostgreSQL itself”
I hope this is not a scenario that becomes too common. Thankfully, most companies in my area know of PostgreSQL, but have not heard of EnterpriseDB. It is disappointing to hear a single company is harming the reputation of an otherwise good project.
Curt certainly brings up some disturbing concerns about EnterpriseDB. As a PostgreSQL core team member and EnterpriseDB employee, if Curt’s perceptions were wide-spread, I think I would have heard about it, though it is possible I am so far separated from EDB sales that I am missing something.
I am sure EnterpriseDB would love to talk to Curt to learn more about the details and to see if things can be improved.
Hi Bruce,
I discussed it with two consecutive EnterpriseDB marketing VPs, to no satisfaction.
Glad to see Bruce participating in this discussion. Perhaps something good can come of it, if Bruce brings this to the attention of others in the EnterpriseDB organization?
EnterpriseDB should be helping to put a brighter light on the PG project, not harming its image (if that is indeed the case).
IBM acquired Netteza!
Not sure How IBM will position Netteza and its home developed DB2 Data warehouse system.
Curt, any comments?