Elixir has carved out a serious place in data infrastructure: Phoenix dashboards over live data, Broadway pipelines feeding warehouses, GenStage systems that shuttle events all day without dropping one. What Elixir never had was a way to talk to IBM Netezza. There is no hex package for it, no Ecto adapter, nothing. Teams bridged the gap with ODBC ports or HTTP sidecars, both of which add a moving part precisely where you least want one.
So we wrote the driver: pure Elixir, built entirely on what ships with Erlang/OTP. :gen_tcp carries the appliance’s wire protocol, :crypto handles the login hashing, :ssl does TLS. The dependency list in mix.exs is empty, which means it builds on an air-gapped machine and adds nothing to your supply-chain surface.
Binary pattern matching was made for this
A wire protocol decoder is where Elixir shows off. Netezza’s real table scans arrive as the appliance engine’s binary tuples, little-endian, with a null bitmap and packed fields, and destructuring them with binary pattern matching reads almost like the protocol specification itself. The driver decodes the full type system: every integer width, 38-digit numerics (arbitrary-precision integers make the four-word case trivial), dates, times, timestamps, intervals, and both character families, including the European encoding Netezza uses for CHAR and VARCHAR on disk. Accents, euro signs and Chinese come back byte-exact, verified live.
Parameters are bound injection-safely, quotes doubled, backslashes deliberately untouched because on Netezza a backslash inside a string is a literal character. Bind o'brien; DROP TABLE x-- and it comes back as exactly that inert string.
Old racks taught us two OTP lessons
Like the rest of our driver programme, this one uses a single connect-time code path that classic NPS 7.x racks and current NPS 11 systems both accept, and every feature was tested live against both before we called it done. External tables, the appliance’s high-speed bulk load and unload, work in both directions, log-file diagnostics included.
TLS surfaced two details worth writing down. First, a plain elixir script.exs run does not start the :ssl application for you; the driver now ensures it. Second, and more interesting: OTP 26’s default TLS client hello is modern enough that an old NPS 7 rack simply refuses it, because the appliance wants legacy protocol versions and cipher suites that current defaults no longer offer. The driver offers the full range explicitly when the appliance asks for TLS, so security_level: 3 encrypts the session on a 2014 rack and a current system alike.
Honest edges
This is the wire layer done properly, not an Ecto adapter; that can come later on top of it. The connection is a plain struct used from one process at a time, because the protocol itself is strictly request/response; wrap it in a GenServer or a pool when you need sharing, the way you would wrap any resource. Publication to hex.pm is coming soon. Until then it is two source files.
An empty deps list is not minimalism for its own sake. It is what lets the same code build in the locked-down environments where these appliances actually live.
Where you get it
We did not build this for ourselves. Our software is written in Python, so nothing in our stack uses it; it exists because the gap did, and because other teams kept falling into it. If your Elixir pipeline has been reaching Netezza through an ODBC port that falls over on redeploys, the moving part is gone. Talk to us if you want it 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.
