Connecting Apps to Autonomous Database

Autonomous Database removes most of the database administration burden, but it does not remove the need to connect applications to it correctly, and connectivity is where many teams hit their first friction. The connection model on Autonomous Database is deliberately secure, which means it works differently from the plain connection strings developers may be used to, and the differences trip up teams who expect to point an application at a host and port and be done. This guide explains how applications connect to Autonomous Database, the choices you make along the way, and the patterns that keep connectivity both secure and performant.

Why the connection model is different

Connections to Autonomous Database are encrypted by default and authenticated using credentials that the platform issues, rather than the unencrypted host and port connections that older database deployments often allowed. This is a deliberate security posture. Traffic between the application and the database is protected in transit, and the database will not accept a connection that does not present the right credentials. For teams moving from a self managed database where any client on the network could open a connection, this is a change in mindset as much as a change in configuration, and understanding why the model is built this way makes the configuration steps feel less arbitrary.

The practical consequence is that connecting an application is not just a matter of a connection string. You provide the application with the means to establish a secure, authenticated session, and the exact means depends on which security model you choose. Getting this right once, in a repeatable way, saves a great deal of trial and error later when new services need to connect.

Wallets and mutual TLS

The traditional way to connect to Autonomous Database uses a wallet, a bundle of files that contains the credentials and trust information the client needs to establish a secure mutual TLS session. The application downloads the wallet, stores it securely, and points its connection configuration at it. Mutual TLS means both the client and the database authenticate each other, which is a strong security model, and the wallet is the artefact that carries the client side of that trust.

Wallets are reliable and well understood, but they introduce an operational consideration, which is that the wallet is a credential and must be managed like one. It needs to be stored securely, distributed to the services that need it without leaking, and rotated when policy requires. Treating the wallet casually, for example checking it into a code repository, is a security mistake, and a managed estate handles wallet storage and rotation as a deliberate practice rather than an afterthought.

TLS without a wallet

Autonomous Database also supports one way TLS connections that do not require a wallet, which simplifies the connection story for some applications by removing the wallet management overhead. This option is attractive when the operational cost of distributing and rotating wallets is high, or when a framework does not handle wallets gracefully. The trade off is in the security model, because one way TLS authenticates the database to the client but relies on the database credentials alone for the reverse direction rather than the mutual certificate based authentication a wallet provides.

The choice between wallet based mutual TLS and wallet free TLS is a security and operations decision rather than a purely technical one. For workloads with strict requirements, mutual TLS and its stronger client authentication is often the right answer despite the wallet overhead. For others, the simpler connection model is a reasonable and supported choice. The important thing is to make the decision deliberately and document it, rather than defaulting to whatever the first tutorial showed.

Service names and connection profiles

Autonomous Database exposes several service names, each tuned for a different kind of workload, and choosing the right one is part of connecting an application well. The service names map to different priorities, with some favouring high concurrency and low resource use per session and others favouring more resources per session for heavier work. An application that picks the wrong service name can either starve itself of resources or consume more than it needs, so matching the service name to the workload pattern matters.

For a transaction processing workload with many small concurrent requests, the higher concurrency service names are usually the right fit, while a reporting or batch workload with fewer but heavier queries benefits from a service name that grants more resources per session. This mapping is straightforward once you understand it, and it is the kind of detail that separates a connection that performs well from one that mysteriously underperforms. The related guidance in our performance tuning guide covers how service name choice interacts with the overall performance picture.

Connection pooling

Because establishing a secure session has a cost, applications that open and close connections for every request waste effort and add latency, which is why connection pooling is essential rather than optional for Autonomous Database. A pool keeps a set of established connections ready and hands them to the application as needed, amortising the connection cost across many requests. Most application frameworks and database drivers support pooling, and configuring it correctly is one of the highest value connectivity tasks.

The pool needs to be sized sensibly, large enough to serve concurrent demand without queuing but not so large that it exhausts the database session capacity, and this sizing should be based on the actual concurrency the application sees rather than a guess. An oversized pool can overwhelm the database, while an undersized one creates artificial waiting, so the pool size is a parameter worth measuring and tuning rather than leaving at a default. Combined with the right service name, a well configured pool is the foundation of responsive connectivity.

Private endpoints and network placement

By default Autonomous Database is reachable over a public endpoint, but most production workloads should connect over a private endpoint inside a virtual cloud network, which keeps database traffic off the public internet entirely. A private endpoint places the database connectivity inside your network, so applications reach it over private addresses and the database is not exposed publicly. This is a significant security improvement and is the right default for production, with the public endpoint reserved for development convenience or specific access patterns.

Network placement also interacts with how applications resolve and reach the database, and getting the network design right is part of making connectivity reliable rather than a source of intermittent failures. The full detail of private endpoint configuration is covered in our private endpoints and networking guide, and the broader security posture in the security features guide. For production, plan the private endpoint into the landing zone from the start rather than retrofitting it later.

A connectivity framework

Bringing it together

Connecting applications to Autonomous Database is more deliberate than connecting to an old style database, because the platform is secure by default, and that deliberateness pays back in security and reliability once the patterns are in place. Choose a security model and stick to it, treat wallets and credentials as the secrets they are, match service names to workloads, configure pooling against real concurrency, and place production databases behind private endpoints. None of these steps is difficult, but skipping any of them creates friction that looks like a database problem when it is really a connectivity one. The companion guides on private endpoints, performance tuning and security features complete the picture, and the pillar guide to Autonomous Database on OCI sets it in context. When you want connectivity designed and built correctly from the start, our implementation work covers it.