Building a Proxy So Two Systems Get Along

Several of the clients my company works with run Qlik Cloud on top of Exasol. Exasol holds the large, fast analytical data; Qlik is where people actually ask their questions. The two are good at different things, and the interesting work is in how they meet.

Qlik Cloud has a feature called Direct Query. Instead of pulling a whole dataset into its in-memory engine, it leaves the data in the source and pushes SQL down to it live, as the user selects and filters ^[R4]. For a table of a few hundred million rows that nobody wants to reload, that is the right trade: the heavy lifting stays where the data already is, and Qlik becomes the place you steer from rather than the place everything has to fit. Direct Query runs against a fixed list of sources. Snowflake, Databricks, BigQuery, SQL Server, Redshift, Azure SQL, and PostgreSQL are on it ^[R4]. Exasol is not.

The supported way to reach a system Qlik cannot see directly is Qlik's Direct Access gateway. It is built for firewalled and VPC-locked data: Qlik sends a load statement, the gateway relays it, and the rows stream back into the cloud ^[R5]. It works, and for plenty of cases it is exactly right. But it loads. It does not push the query down and run it in tandem with the user's selections, which was the entire reason for wanting Direct Query against Exasol in the first place. Using the gateway to solve this gives up the benefit you were reaching for.

So there is a gap with an obvious shape. Qlik will happily push queries down to a PostgreSQL source. Exasol is not PostgreSQL. Put something in between that speaks Postgres to Qlik and Exasol to Exasol, and the gap closes.

That something is a proxy: a small piece of software that speaks one system's language on the side facing you and a different system's language on the side facing the thing you want to reach. You talk to it as if it were the second system. It does the translation and forwards the request. When it works, neither end knows the other was never designed for it.

I had been suggesting exactly this to Exasol for about three years. Build a PostgreSQL or MySQL compatible front-door, I kept saying, and every tool that already speaks those protocols can reach Exasol without a native driver. Nothing happened, and at the time that was a defensible call on their part. Implementing a wire protocol was weeks of careful work before you reached the first edge case, so it needed a clear payoff to justify the build, and the idea sat in the reasonable-but-not-now pile.

What changed was not the idea. It was the cost.

Why an agent is suited to this in particular

Most code an agent writes asks it to guess at intent. What should this function do at the boundaries nobody specified? What did the person actually want? Protocol implementation is the rare category where that guessing is almost absent, and that is exactly why an agent is good at it.

A wire protocol is documented down to the byte. Which message types exist, the order they arrive in, how a length prefix is encoded, what the server must say back and when. There is no design to argue about and no taste to exercise, only faithful implementation of something that already exists in a specification. Hand an agent the protocol document and the upstream system's behaviour, and it produces a working draft of the translation layer faster than you could type the message-parsing boilerplate by hand. The happy path, a normal query in and a normal result out, really is close to a weekend now.

So I built it, instead of waiting another three years. The result is ExaProxy: it presents Exasol over the PostgreSQL wire protocol, so Postgres-speaking tools, Qlik and diagnostic clients like DBeaver among them, can connect to Exasol with no native driver.

The reason a proxy is worth more than an ordinary script is a different kind of arithmetic. A script joins one specific producer to one specific consumer: you write it, you get one connection. A proxy joins to a protocol, and a protocol has a crowd of existing tools behind it. Implement the Postgres wire once and every tool that already speaks Postgres works against whatever sits behind the proxy, untouched. You wrote one adapter and inherited a shelf full of clients.

There is an easy end to this and a hard end, and I have built one of each. The Fiken Proxy is the easy end: it bridges an authentication scheme rather than a query language, a bearer token on one side and a browser-style form login on the other. Contained, narrow, an afternoon. ExaProxy is the hard end, and it is the one worth dwelling on, because it is where the optimistic story breaks.

The part the demo never hits

A wire protocol has corners, because real clients do far more than send SQL and read rows. A Postgres client connects and immediately starts asking catalog questions: what tables exist, what types do these columns have, what encoding are we using, what version is the server. It expects particular metadata in a particular form, and it leans on behaviour the upstream system may not provide at all. None of that is in the SQL you were picturing when you imagined the proxy, and all of it has to be answered convincingly, or the client refuses to proceed, or worse, proceeds on a wrong assumption.

The happy path earns applause. The corners earn trust, and they cost what they always did.

This is the trap, and it is specific. A proxy that handles the queries and falls over on the catalog interrogation is the worst possible result, because it passes every demo. You connect, you run a SELECT, you see rows, it looks finished. Then a real tool connects, asks the catalog question your demo never sent, and fails for a reason that stays baffling until you have sat and read a packet trace to see what the client expected and what your proxy actually said.

The misleading part is the phrase "it is just a database on the other end." Exasol answers SQL perfectly well. The work is convincing a row of different client drivers, each with its own habits, that they are talking to the Postgres they assume. Take identifier case. PostgreSQL folds an unquoted name to lowercase; Exasol folds it to uppercase. So a client runs SELECT table_name AS name, Exasol hands back a column labelled NAME, and a driver that reads the field as row.name finds nothing and renders every cell blank. The data is right there. The screen shows nothing, and there is no error to chase. Or take paging: a client asks for its first page as LIMIT 100 OFFSET 0. In Postgres the zero offset is a harmless no-op, so nobody thinks about it; Exasol rejects any offset that is not paired with an ORDER BY, so the query fails and the grid comes back empty.

Catalog introspection is where this gets genuinely deep. A schema browser does not ask "what columns does this table have" in any simple way. It reconstructs the answer by walking Postgres system catalogs, leaning on array functions, ::regclass casts, and generate_subscripts that Exasol has no equivalent for, so each of those queries has to be recognised and rewritten natively to return the exact shape the client expects. I ended up building a whole local catalog inside the proxy just to answer them. And the clients do not even agree on how to ask: psql sends a simple query, while DBeaver uses the extended protocol, parsing and binding and executing as separate steps, so a proxy that quietly assumed the simple path mistracks everything the moment a real tool connects. One of my own worst afternoons on ExaProxy was an infinite retry loop: a catalog handler matched a pg_type mention inside a JOIN, answered the wrong question, and the client dutifully asked again, forever.

A proxy is only as good as its worst corner

The happy path is the cheap part and it is the part that demos. The expensive part is the catalog query, the type-metadata edge, the first-row timing, the large-result streaming behaviour, the protocol nicety one specific client insists on. A proxy that is right on the common path and wrong on the corners works perfectly until production, then fails in ways that are hard to even reproduce.

The open edges on ExaProxy are exactly this list: large-query behaviour, first-row timing, schema compatibility. They are unglamorous, they do nothing for the demo, and they are the whole difference between a tool that is genuinely usable and one that works on your machine in the meeting.

Then Exasol shipped the real one

Building ExaProxy was only half of what I did this time. Alongside it, I emailed Nico Conforti, an engineer at Exasol, with the idea, and otherwise kept the prototype to myself. He wrote back that it was an interesting idea and he would check internally, and did not mention that he had quietly started building one too. I only learned that when I followed up a few days later with a description of my POC and some screenshots, and he admitted he had been prototyping the same thing on the side all along.

His did not stay a side project. It moved into Exasol's own labs organisation and became the official, open-source PostgreSQL gateway, announced with Qlik as the connecting tool in the demo ^[R2]. It is the production-grade version of the thing I had been arguing for: written in Rust, MIT-licensed, maintained, and tested against a row of real clients, psql, JDBC, DBeaver, DbVisualizer, Metabase, and Qlik among them ^[R1].

You can read the same fight in its commit history. They rebuilt Beekeeper Studio's CREATE TABLE reconstruction against Exasol's system tables, rewrote primary-key and foreign-key lookups one at a time, and drove reserved-word quoting from Exasol's authoritative 468-word keyword table instead of a hand-kept short list ^[R1]. A build with the engine's own authors behind it had to grind through exactly the corners I had been swearing at, which is the clearest sign I can offer that the edges, not the happy path, are where a proxy actually lives.

It is also built the Exasol-appropriate way. It installs onto the Exasol server itself, so it needs no separate host and no new infrastructure to run. You turn it on where the database already lives. Both implementations leave Exasol as the engine and only translate the protocol in front of it, so neither is really pretending to be Postgres underneath. The difference is where the translator sits. ExaProxy runs as a separate service outside the database, and sitting outside is exactly what lets it do the one thing the official build does not: present several Exasol databases as a single Postgres connection, so a tool that thinks it is talking to one database is really fanning out across a few.

Conforti reshared the announcement and thanked me by name for the initial email and idea that, as he put it, put the wheels in motion ^[R3]. I will admit I enjoyed that more than I expected to. After three years of the idea going nowhere, watching it ship as a real product and getting a generous public nod is about as good as this kind of advocacy gets.

The division of labour is clear enough. Mine was a fun proof of concept; theirs is code you can put in front of a client. My version has done its job. What interests me is how the thing finally got made: the same idea took runnable form twice in parallel, once from me and once from the engineer I had emailed it to, because the cost of building it had fallen to where either of us could just build it instead of arguing for it.

When to reach for one now

For most of my career a protocol-level proxy was a deliberate, serious decision. You did not implement a wire protocol on a whim, because the implementation alone was weeks of work before the edge cases. So the proxy was a last resort, reached for only when the payoff plainly justified the build.

The cost of the first draft has collapsed, and that genuinely changes the calculus. When the happy-path implementation is an afternoon, the proxy moves from last resort to default tactic for the almost-compatible problem. The question is no longer whether you can afford to build it, but whether the tools on the other side are worth inheriting. When you are reaching for a proxy at all, they usually are, because the whole point is that you get every tool that speaks the protocol at once.

The new part is quieter, and it is the one I keep thinking about. A proof of concept is now cheap enough to be an argument in its own right. I spent three years making a case in words and got nowhere; a weekend of code made the same case in a form people could run, and the real version followed. That is a different way to push an idea than I am used to, and I suspect it is becoming a normal one.

But the thing that got cheap is the part that was never the hard part. The edge cases are as expensive as they ever were. An agent will faithfully implement a documented protocol and will not, on its own, discover that one specific client sends an undocumented startup query the others skip, or that your streaming stalls a result set in a way that only shows up past ten thousand rows. That discovery is empirical. It comes from connecting real clients and watching real traffic. It is human work with an agent assisting, not work you can hand over whole.

The demo was the argument

For three years I had pitched this in words, and words got me as far as a polite note that the idea was interesting and someone would check internally. This time the words came with running code, and, it turned out, so did his. The email reached the right person, but what let either of us act on it was that building the thing had stopped being a project and become a weekend. He could prototype on the side; I could answer with screenshots instead of a slide; and the version with Exasol behind it became the product. I cannot tidy this into my demo being the cause. The smaller point is the one that stays with me: the idea sat untouched through three years of advocacy and moved the moment it got cheap enough to simply build. The payoff of a proxy was always real. What changed is that proving an idea is worth building no longer takes a budget, only a weekend and a steady respect for the corners the demo will never show you.

_{Building a Proxy So Two Systems Get Along · July 2026 · A Tools & Automation piece. ExaProxy and the Fiken Proxy are the author's own projects; Exasol's exa-postgres-interface is the official build that shipped in parallel. The read on where proxy effort actually goes is the author's argument.}