Connect OCI Database with PostgreSQL to Excel, Sheets and AI

There is no public endpoint, and that turns out to be the easy case

Normally a private database is the awkward one. Here it is the opposite, because the agent was already built for exactly this shape.

• OCI Database with PostgreSQL is VCN-private by design. There is no public hostname to enable and no setting that would give you one.
• So any tool that connects inward from its own cloud cannot reach it, and the usual workarounds — a bastion host, a public subnet, a VPN back to the office — all mean widening something.
• The agent does not connect inward. Put it on a Compute instance in the same VCN and it is simply a client on the private network, then it opens one outbound connection to Query Streams for everything else. Nothing about the VCN changes.
• That outbound connection is the only route in or out, and no inbound security-list rule is needed to create it. The database stays exactly as private as it was before you connected it to a spreadsheet.

Branding rides the saved connection, because a private IP looks like any other

A small consequence of being private that is worth explaining, since it makes this card behave slightly differently from the rest.

• Every other hosted card here recognises its provider from the hostname — .neon.tech, .render.com, .aivencloud.com. There is no OCI equivalent, because your endpoint is a private address inside your own network and could be anything.
• So this preset is identified by having chosen the card, rather than by the address. Picking it is what records that this is OCI.
• Nothing about the connection depends on that; it is the badge and the branded defaults, not the wire protocol. Underneath it is PostgreSQL and the agent carries the Npgsql driver.
• It does mean the card is worth choosing over generic PostgreSQL even though both would connect. Heroku is the only other preset in the same position, and for the same reason.

Encryption follows the checkbox, and the private network is why

Most managed Postgres cards here say the agent forces TLS whatever the checkbox says. This one does not, deliberately.

• The SSL checkbox is on by default, and left on the connection is encrypted. That is the normal path and needs no attention.
• The agent does not override it, because a VCN-private DB system with TLS switched off is a legitimate configuration and forcing encryption would break a connection that was working. Traffic on a private subnet never crosses the public internet.
• So the instruction is simply: leave it on unless your DB system has TLS disabled, in which case clear it.
• When encryption is on, the certificate chain is not verified. Read it as protection against anyone reading the traffic in transit, rather than as proof of which server answered.
• Everything the agent runs is read-only, credentials stay on the Compute instance you installed it on, and Query Streams keeps no copy of your data.

-- Ordinary Postgres, read-only, from inside the VCN\nSELECT   c.name,\n         COUNT(o.id)   AS orders,\n         SUM(o.amount) AS revenue\nFROM     public.customers AS c\nJOIN     public.orders    AS o ON o.customer_id = c.id\nWHERE    o.placed_at >= now() - interval '30 days'\nGROUP BY c.name\nORDER BY revenue DESC;