June 26, 2010

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 EnterpriseDBinfused 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: 

Comments

19 Responses to “Netezza’s version of EnterpriseDB-based Oracle compatibility”

  1. Matt on June 26th, 2010 10:04 pm

    “EnterpriseDB has some deplorable business practices” – I could not find any examples of these stories. Could you elaborate?

  2. Curt Monash on June 27th, 2010 1:47 am

    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.

  3. Todd Fin on June 27th, 2010 1:55 am

    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.

  4. Curt Monash on June 27th, 2010 2:04 am

    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.”

  5. Serge Rielau on June 27th, 2010 6:40 am

    @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

  6. Curt Monash on June 27th, 2010 7:40 am

    @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

  7. Matt on June 27th, 2010 10:58 am

    @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.

  8. Curt Monash on June 27th, 2010 4:18 pm

    @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.

  9. Todd Fin on June 27th, 2010 4:46 pm

    @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

  10. Curt Monash on June 27th, 2010 6:56 pm

    @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).

  11. Tim Young on June 28th, 2010 8:11 am

    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.

  12. Serge Rielau on June 28th, 2010 8:38 am

    @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

  13. Curt Monash on June 28th, 2010 1:35 pm

    @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 😉

  14. My talk this morning | DBMS2 -- DataBase Management System Services on June 28th, 2010 3:05 pm

    […] How Netezza Migrator works […]

  15. Matt on June 28th, 2010 10:22 pm

    “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.

  16. Bruce Momjian on June 29th, 2010 12:33 pm

    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.

  17. Curt Monash on June 29th, 2010 1:20 pm

    Hi Bruce,

    I discussed it with two consecutive EnterpriseDB marketing VPs, to no satisfaction.

  18. Matt on June 29th, 2010 1:51 pm

    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).

  19. Yunfeng Sun on September 20th, 2010 10:22 am

    IBM acquired Netteza!
    Not sure How IBM will position Netteza and its home developed DB2 Data warehouse system.
    Curt, any comments?

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.