Data teams stopped writing extraction scripts years ago. The code-first ones standardised on Singer, the open specification where a “tap” extracts from a source and a “target” loads into a destination, both speaking a simple stream of JSON messages, orchestrated by Meltano. Hundreds of taps and targets exist for it. Netezza had neither, so every Netezza-to-anything or anything-to-Netezza pipeline meant custom code, usually wrapped around an ODBC connection nobody enjoyed maintaining.
We have added the missing two: tap-netezza and target-netezza. With them, Netezza becomes an ordinary participant in the Singer ecosystem, on either end of a pipe.
Two tools, one pipe
tap-netezza runs a query and emits the Singer message stream: a SCHEMA describing the columns, a RECORD per row, and a STATE bookmark, all as JSON lines. target-netezza does the reverse: it reads that stream, creates the destination table from the schema, and loads the records. Because both sides speak the standard, they compose with everything else in the ecosystem. Pipe a Salesforce tap into target-netezza to land CRM data in the warehouse; pipe tap-netezza into a Snowflake target to move the other way; or run tap-netezza straight into target-netezza to copy between Netezza databases, which is exactly the round-trip our live test exercises against both a classic NPS 7.2 rack and a current NPS 11.2 system, nulls and all.
Both tools are pure Python on aionetezza, our async-native driver, so there is no ODBC layer to install on the machine or in the orchestrator’s container. They are console commands with the conventional --config flag and --discover mode, so Meltano treats them as first-class plugins.
Types that survive the trip
The interesting work in an ELT connector is always types. On extract, tap-netezza maps each Netezza column to a JSON-Schema type so downstream targets know what they are receiving. On load, target-netezza does the reverse, turning JSON-Schema back into Netezza column types and creating the table. Integers, booleans, dates, timestamps and text all round-trip cleanly, and a SQL NULL stays null in both directions, which our test checks with a null in a numeric column. The one honest wrinkle is that Singer’s number type carries no scale, so a NUMERIC(12,2) arriving at the target lands in the target’s default wide-scale numeric: the value is preserved exactly, the declared width just changes. That is inherent to the spec, and we document it rather than hide it.
Honest scope
target-netezza loads with batched, injection-safe single-row INSERTs, which is portable to older NPS 7 appliances that lack multi-row VALUES and is the right default for a reference connector. For very high volumes the natural upgrade is staging through external tables, Netezza’s bulk path, which our drivers already speak; that is a refinement on the roadmap rather than in this first release. Publication to PyPI and the Meltano hub is coming soon.
A warehouse that isn’t in the ELT ecosystem is a warehouse people route around. Netezza is in it now.
Where you get it
We built this for the Netezza community rather than as a product of our own. If your team runs Meltano or Singer and has been treating Netezza as the special case that needs hand-written glue, it no longer is. Talk to us if you want them in your own estate.
Built from the published open source Netezza drivers (IBM/nzpy and IBM/nzalchemy under Apache-2.0, IBM/nzgo under MIT), verified live against both NPS 7.2 and NPS 11.2, and produced without decompiling, disassembling or inspecting any IBM proprietary binary.
Running Netezza? Let’s talk. Smart Associates has been engineering on IBM Netezza for two decades: disaster recovery, migrations, performance and the deep platform work in between. If any of the above sounds familiar, why not get in touch.
