Why TuneVault runs on Oracle 26ai — and why it matters for Oracle DBAs

TuneVault now runs entirely on Oracle. Compute on Oracle Cloud Infrastructure, data on Oracle 26ai Autonomous Database, vector search on Oracle's native VECTOR type. Zero non-Oracle infrastructure. Here's the story of how we got here, the technical decisions along the way, and what it means if you run Oracle for a living.

The short version

A monitoring platform for Oracle databases should run on Oracle. That's the whole thesis. We used to run our own application data on a managed Postgres and a general-purpose cloud host — perfectly fine engineering, but it always sat a little wrong: we were asking DBAs to trust an Oracle tool that wasn't itself built on Oracle.

So we moved. The TuneVault application — every health-check result, every ticket, every AI knowledge chunk — now lives in an Oracle 26ai Autonomous Database, and the app runs on an OCI Compute VM. Same product, same features, same prices. Different foundation.

The technical decisions (the part DBAs actually care about)

Migrating a live application database from PostgreSQL to Oracle is not a expdp/impdp job. It's a dialect translation, a driver change, and a data migration — each with its own traps. A few worth calling out:

Thin-mode node-oracledb, no Instant Client. The app connects with node-oracledb 6.x in thin mode — pure JavaScript, no Oracle client libraries to install, mTLS to the Autonomous DB via the wallet. That keeps the deploy trivial and, as a bonus, runs unmodified on ARM (Ampere) compute. No LD_LIBRARY_PATH, no client/server version matrix.

Postgres → Oracle 26ai, honestly translated. Oracle 23ai/26ai has native BOOLEAN and native binary JSON, so most of our types mapped cleanly instead of degrading to NUMBER(1) and CLOB-of-JSON. Postgres text[] columns became JSON arrays. INSERT … ON CONFLICT upserts became MERGE. RETURNING * became RETURNING … INTO with a read-back. Identity columns replaced SERIAL. None of it exotic — but all of it has to be right, because a monitoring tool that miscounts is worse than no monitoring tool.

pgvector → Oracle's native VECTOR. TuneBot — our in-dashboard Oracle assistant — retrieves from a corpus of Oracle documentation. That was a pgvector store; it's now VECTOR(1536, FLOAT32) in Oracle 26ai, migrated bit-exact, with approximate-nearest-neighbor search returning in roughly 120 ms across ~22k chunks. The retrieval layer is now Oracle-native. (To be clear about what's Oracle and what isn't: the retrieval runs on Oracle 26ai vector search; the language model answering you is still Claude/OpenAI. We don't overclaim that.)

A durable queue instead of LISTEN/NOTIFY. Our agent command channel used Postgres LISTEN/NOTIFY, which has no Oracle equivalent. Rather than bolt on a message broker, we moved to a durable table-backed queue using SELECT … FOR UPDATE SKIP LOCKED for at-most-once claiming. Simpler operationally, and it survives a restart.

The subtlest issue we hit: Oracle's JSON_TRANSFORM function produces OSON v2 format that node-oracledb 6.x cannot read back. The failure doesn't surface at write time — it silently corrupts reads on unrelated queries later. We replaced all JSON array appends with SELECT FOR UPDATE read-modify-write transactions. This is the kind of thing you only discover by running the migration against a live database with real traffic.

A cutover you could roll back with one environment variable. The whole migration was built in parallel — the old stack stayed live the entire time. The database backend is chosen by a single switch, so cutover was a config flip, not a redeploy, and rollback is the same flip. After the flip we reconciled every table between the two databases, row by row, to confirm nothing was lost in the window. (It wasn't.)

What it means for customers

Your Oracle monitoring platform is now itself an Oracle deployment. If you're evaluating a tool to watch your most important databases, "we run on the same technology you do" is not marketing — it's a statement about where our expertise and our incentives point.

Your data stays on Oracle Cloud. TuneVault Cloud's infrastructure and data storage are entirely Oracle Cloud Infrastructure and Oracle 26ai Autonomous Database. (The only thing that ever leaves is redacted, anonymized SQL text sent to the AI providers for analysis — bind values stripped, no business data — exactly as before, and always disclosed on our Trust page.)

You can deploy on your own OCI tenancy. Self-hosted TuneVault has always run in your network. Now there's a first-class path to run it on an OCI Compute VM in your own tenancy — Oracle Linux, thin-mode driver, no Instant Client. Same product, your cloud.

We use what we sell. Every Oracle-native decision above is one we now live with in production, on Oracle, every day. When we tell you native VECTOR search is fast enough for interactive retrieval, or that thin-mode deploys are painless on ARM, it's because we ship on it — not because we read the docs.

The point

TuneVault was built by an Oracle DBA and Architect with two decades inside Oracle production systems, for the DBAs who live there too. "Built by DBAs, for DBAs" was always about the checks, the runbooks, the 4am incidents encoded into the product. Running the whole thing on Oracle Cloud Infrastructure and Oracle 26ai is that same idea, taken all the way down to the foundation.

Oracle-native, top to bottom. That's the whole point.

Want to run TuneVault on your own OCI tenancy? Email [email protected] for the OCI deployment guide. Or try the cloud version free.