Nothing. Not a cent. Oracle counts a vCPU on Amazon RDS exactly the way it counts a vCPU on Amazon EC2, and it says so in the same paragraph of the same policy document. The managed service does not buy you a discount on the software.

That single fact reshapes the whole argument. Once the license line is identical on both sides of the page, Oracle on EC2 vs RDS stops being a cost comparison and becomes a much more interesting question: which set of constraints can your application actually live inside? This post walks through the real differences, the places each option quietly hurts, the middle option that is being retired, and a decision procedure you can run before anyone opens a pricing calculator.

Start with the thing that is not a difference

Oracle publishes a policy called “Licensing Oracle Software in the Cloud Computing Environment.” It names a short list of Authorized Cloud Environments, and both Amazon EC2 and Amazon RDS are on it, alongside Microsoft Azure and Google Cloud Platform. Inside an Authorized Cloud Environment the counting rules are these:

• Two vCPUs count as one Oracle Processor license when multi-threading of processor cores is enabled.
• One vCPU counts as one Processor license when multi-threading is not enabled.
• The Oracle Processor Core Factor Table does not apply. The 0.5 multiplier you rely on for x86 hardware in your own data center is simply gone.
• For Standard Edition products, instances with four or fewer vCPUs count as one socket. Above four, every four vCPUs rounded up to the nearest multiple of four equals one socket.
• Standard Edition 2 may only be licensed on instances up to eight AWS vCPUs. That is a hard ceiling, and it is the single most common reason an SE2 estate has to become an Enterprise Edition estate on migration.

None of those rules distinguish EC2 from RDS. The policy treats them as the same environment for counting purposes.

There is one genuine licensing difference, and it is narrow. RDS offers a License Included model where AWS holds the Oracle license and bundles it into the instance-hour rate. That model covers Standard Edition 2 only. Enterprise Edition on RDS is bring-your-own-license, full stop. On EC2 there is no License Included option at all, so every Oracle database you run there is BYOL by definition.

Worth reading the footer of that Oracle policy document, too. It states that the document is for educational purposes and may not be incorporated into any contract. Your Oracle Master Agreement and ordering documents are what actually bind you. The cloud policy is how Oracle says it will behave, not what it promised in writing, and it can change without notice. Pin a copy of the version in force when you deploy and file it with your architecture decision record.

Find out what you are actually using first

Before you compare anything, find out which licensable options and management packs your current database is touching. Oracle tracks this itself. The feature usage view records every separately licensed feature the database has detected in use, which is exactly what an auditor looks at.

-- Which separately licensed features has this database touched?
SELECT name,
       detected_usages,
       currently_used,
       first_usage_date,
       last_usage_date
FROM   dba_feature_usage_statistics
WHERE  detected_usages > 0
ORDER  BY name;

Oracle also publishes an options and packs usage script through My Oracle Support that goes further and correlates usage across several dictionary views. If you have a support contract, use that one rather than rolling your own. The output frequently surprises people. Partitioning, Advanced Compression, and the Diagnostics and Tuning Packs get switched on by a well-meaning DBA or by a default setting and then sit there generating an entitlement gap.

Amazon RDS for Oracle: where it wins and where it hurts

Where RDS wins

• The operational floor is done for you. Automated backups with point-in-time recovery, minor version patching in a maintenance window, Multi-AZ synchronous standby with automatic failover, storage autoscaling. None of that needs a person on a rota.
• License Included removes the Oracle relationship entirely. For an SE2 workload where you own no licenses, this is genuinely hard to beat. There is no entitlement to track, no support renewal to chase, and no Oracle audit surface for the database software.
• Read replicas are configured for you. RDS manages the Data Guard setup behind cross-region replicas, including the network path between primary and standby. If the replica runs open read-only, that is Active Data Guard and you need the license for it, but the plumbing is not your problem.
• Parameter groups make configuration reviewable. Database parameters live in a versioned object you can diff, rather than in a spfile someone edited at two in the morning.

Where RDS hurts

The master user on an RDS for Oracle instance gets the DBA role with pieces removed. AWS documents exactly which privileges are withheld to keep the managed experience intact:

• ALTER DATABASE
• ALTER SYSTEM
• CREATE ANY DIRECTORY and DROP ANY DIRECTORY
• GRANT ANY PRIVILEGE and GRANT ANY ROLE

You also cannot log in as SYS, SYSTEM, or any other Oracle-supplied administrative account. This is the wall most migrations hit, and they hit it late. A packaged vendor application ships an installer that expects to connect as sysdba, create a directory object pointing at a local path, and run ALTER SYSTEM a dozen times. On RDS that installer does not complete. There is no workaround, because the privilege is not withheld by policy, it is withheld by design.

Three more constraints that bite later rather than sooner:

• Block size is fixed at creation. RDS for Oracle instances are created with an 8 KB default block size and it cannot be changed afterwards. The SYSTEM and temporary tablespaces always use it. You can create additional tablespaces at other block sizes by allocating the matching cache parameter and using the BLOCKSIZE clause, but the core of the database is fixed.
• Single files cap at 16 TiB. That is the ext4 filesystem limit on the underlying host, so bigfile data files inherit it. Try to grow past it and you get an ORA-01237 with a “File too large” error underneath.
• No host access at all. No shell, no third-party backup agent, no monitoring agent installed on the database server, no custom scripts on the filesystem. If your compliance tooling or your APM vendor requires an on-host agent, that requirement decides the platform for you.

Oracle on EC2: where it wins and where it hurts

Where EC2 wins

• Full sysdba and full root. Everything the vendor installer wants is available. Directory objects, external tables reading from local paths, custom PL/SQL that shells out, agents, whatever the packaged application assumed about its host.
• The full replication toolbox. Data Guard, Active Data Guard, and GoldenGate all run natively on EC2, and you control the protection mode, the apply lag tolerance, and the failover behaviour rather than accepting a managed default.
• Instance shape is a license lever. This is the underrated one. Oracle bills you on vCPUs, and most Oracle databases are memory bound rather than thread bound. On EC2 you can pick a memory-dense family and hit your SGA target without buying vCPUs, and therefore licenses, that the workload never uses. RDS gives you a narrower catalogue to choose from.
• You choose when to patch. No maintenance window imposed from outside, no forced minor version upgrade, no surprise reboot on a night your business cannot take one.
• Storage is yours to shape. Separate EBS volumes for data, redo, and archive logs, with independent IOPS and throughput. RDS abstracts that away.

Where EC2 hurts

Every one of those wins is a job someone now has to do, forever. The honest cost of Oracle on EC2 is not the instance-hour, it is the rota.

• Backups you have to prove. RMAN to S3 is a solved pattern, but a backup that has never been restored is a hypothesis. Schedule a real restore into a throwaway instance on a cadence and treat a failed restore as an incident.
• A standby that drifts silently. Data Guard apply lag is the classic invisible failure. Everything looks green, the standby is mounted, redo is shipping, and apply stopped three days ago because of a single nologging operation or a filesystem that filled. You find out during the failover.
• Patching is now a project. Quarterly Oracle patches, OS patches, and the interaction between them. On a Data Guard pair that means a standby-first sequence and a rollback plan.
• Monitoring you have to build. Tablespace growth, apply lag, wait events, ASM disk group headroom, archive log destination fullness. Amazon CloudWatch gets you host metrics and nothing about the database. Teams typically land on a Prometheus exporter feeding Grafana, either self-hosted or through Grafana Cloud or Amazon Managed Grafana, plus alerting that someone actually answers.
• Cost attribution gets murky. Instance, EBS, snapshots, cross-AZ traffic, and the license amortisation all land in different places. A cost visibility tool such as Vantage or CloudZero earns its keep here, because the Oracle line is the one finance will ask about.

The middle option that is being retired

For a while the answer to “I need sysdba but I also want managed backups” was Amazon RDS Custom for Oracle. It gave you shell access to the underlying EC2 instance and sysdba on the database, while keeping automated backups and host recovery, policed by a mechanism called the support perimeter that flagged your instance as unsupported if a change broke the automation.

AWS has announced that support for RDS Custom for Oracle ends on 31 March 2027. After that date the console and the resources go away, including instances, snapshots, and custom engine versions. AWS’s own guidance is to move those workloads to self-managed Oracle on EC2.

This is one of the few dates worth putting in an article, because it removes an option from your decision tree. If you are choosing a platform today, RDS Custom for Oracle is not a candidate. If you are already on it, the migration is on your roadmap whether you have written it down or not. Note that this retirement does not touch RDS for Oracle or RDS Custom for SQL Server.

The cost levers that actually move the number

Once you accept that the platform choice does not change the license rate, these are the things that do change the bill.

1. Memory-to-vCPU ratio. Reaching a memory target by moving up within a general purpose family buys vCPUs you did not need, and each pair of them is another Processor license. Picking a memory-optimised family instead is often the largest single saving available.
2. Multi-AZ under BYOL doubles the count. AWS states this plainly in its own documentation: under BYOL you must have a license for both the primary and the standby DB instance in a Multi-AZ deployment. Enabling the checkbox on a BYOL instance without buying the second set of licenses puts you out of compliance the moment it comes up.
3. Options and management packs. These are priced per Processor on top of the database license. On RDS, option groups can put some of them one click away, which is convenient and expensive in equal measure.
4. Edition, forced by the vCPU ceiling. SE2 stops at eight vCPUs in an Authorized Cloud Environment. A workload that needs more compute has to move to Enterprise Edition, and that is a different order of magnitude, not a percentage increase.
5. Infrastructure commitments. Reserved Instances and Savings Plans reduce the AWS side of the bill on both platforms. They do nothing to the Oracle side.

Two quick checks worth running before you model anything. First, confirm what an instance is actually presenting, because the multi-threading state is what decides whether you divide by two:

# On an EC2 instance: threads per core tells you the multi-threading state.
# "Thread(s) per core: 2" means the 2 vCPU = 1 Processor rule applies.
lscpu | grep -E 'Thread(s) per core|Core(s) per socket|^CPU(s):'

Second, check what your existing RDS instances are declaring, since the license model and the Multi-AZ flag together determine your exposure:

# Every Oracle RDS instance with its class, license model and Multi-AZ state.
aws rds describe-db-instances 
  --query "DBInstances[?starts_with(Engine, 'oracle')].
[DBInstanceIdentifier,Engine,DBInstanceClass,LicenseModel,MultiAZ]" 
  --output table

A MultiAZ value of true next to a LicenseModel of bring-your-own-license is the line to look at twice.

How I would decide between Oracle on EC2 vs RDS

Run these in order. The first question that returns a hard “no” makes the decision for you, and you can stop.

1. Does anything need sysdba or host access? Vendor installers, on-host agents, directory objects pointing at local paths, external tables reading local files, custom OS-level jobs. If yes, it is EC2. Nothing else in this list matters.
2. Run the feature usage query. Establish which options and packs you are on the hook for today. That number travels with you regardless of platform, and it is usually larger than the team expects.
3. Check the physical constraints. Non-8 KB block size on the SYSTEM tablespace, or a single data file heading past 16 TiB, both rule RDS out.
4. Settle the edition. If SE2 fits inside eight vCPUs and you own no perpetual licenses, RDS with License Included is very hard to argue against. If you need Enterprise Edition, you are BYOL on either platform and the licensing argument is over.
5. Count licenses at the shape you would really run. Production instance, plus standby if you want Multi-AZ or Data Guard, plus every option pack from step two. Do this before you look at instance-hour rates, because it is the bigger number.
6. Price the rota honestly. Who runs restore tests, who owns the patch calendar, who gets paged at three in the morning when apply lag alerts. If the answer is “we will figure it out,” that is a vote for RDS.
7. Pick, then write down why. Record the Oracle policy version you counted against and the instance shapes you assumed. When an audit letter arrives, that document is the difference between a conversation and a negotiation.

One useful side effect of building a dev or reporting copy outside AWS entirely: a modest VPS from a provider like Contabo or InterServer running Oracle’s free Express Edition gives developers a schema to work against without touching a licensed instance. It will not stand in for production, but it takes pressure off the environments that cost money.

Arguments that do not survive contact

• “RDS is cheaper because AWS manages it.” Under BYOL the license line is identical. What you save is operational labour, which is a real saving but a different budget line, and you should say which one you mean.
• “We will disable multi-threading to reduce licenses.” Turning it off halves your usable threads and flips the ratio to one vCPU per Processor license. You end up at the same license count with less compute.
• “The core factor gives us 0.5 on x86.” Not in an Authorized Cloud Environment. Oracle states the table does not apply there. This is the source of the widely repeated claim that moving to the cloud doubles Oracle licensing on identical hardware.
• “The standby is passive, so it is free.” AWS documents that BYOL Multi-AZ requires licensing both instances. There is a separate Oracle provision about genuinely cold failover nodes, but a synchronous standby that is always running is not that. Get your specific position confirmed in writing by whoever advises you on Oracle contracts, not from a blog, including this one.
• “Graviton is a different architecture, so it licenses differently.” The cloud policy counts vCPUs. It does not carve out processor architectures on shared tenancy.
• “We will start on RDS and move to EC2 if it does not work.” Technically true and practically expensive. Moving off RDS means a full migration project with a cutover window, not a configuration change. Establish the sysdba requirement before you build, not after.

Frequently asked questions

Is Oracle licensing cheaper on RDS than on EC2?

Under bring-your-own-license, no. Oracle’s cloud policy names EC2 and RDS together and applies the same vCPU counting to both. The only structural difference is that RDS offers a License Included model, which is available for Standard Edition 2 only.

Can I run Oracle Enterprise Edition with License Included on RDS?

No. AWS supports License Included for Standard Edition 2 only. Enterprise Edition on RDS is BYOL, and you need the appropriate licenses with active Software Update License and Support.

Do I need to license the Multi-AZ standby?

Under BYOL, AWS documentation states you must have a license for both the primary and the standby DB instance. Budget for double the Processor count before you enable it. Under License Included the standby is reflected in the instance-hour rate instead.

What is the largest Standard Edition 2 instance I can run on AWS?

Oracle’s cloud policy caps Standard Edition 2 at eight AWS vCPUs. Past that you are into Enterprise Edition. This ceiling catches a lot of migrations that were sized on memory requirements rather than vCPU count.

Can I get sysdba access on RDS for Oracle?

No. The master user receives the DBA role minus a documented set of privileges including ALTER SYSTEM, ALTER DATABASE, CREATE ANY DIRECTORY, and the GRANT ANY privileges, and the Oracle-supplied administrative accounts are not available for login. If an application requires sysdba, EC2 is your platform.

Is RDS Custom for Oracle still a viable middle ground?

Not for new work. AWS ends support for RDS Custom for Oracle on 31 March 2027 and recommends moving those workloads to EC2. Existing users should treat the migration as a scheduled project rather than a future problem.

Does turning off hyperthreading reduce my Oracle license count?

No. With multi-threading enabled the ratio is two vCPUs per Processor license. With it disabled the ratio becomes one to one. The license requirement stays where it was while your available compute halves.

Conclusion

If you remember one thing from the Oracle on EC2 vs RDS comparison, make it this: the platform choice does not change what Oracle charges you. It changes who does the work and what your application is allowed to do.

So run the decision in that order. Establish the sysdba requirement first, because it is binary and it ends the discussion. Count your options and packs second, because that number is usually wrong in the direction that costs money. Compare instance-hour rates last, because it is the smallest term in the equation and the one everyone starts with.

And write down which version of Oracle’s cloud policy you counted against. It is a non-contractual document that can change, and the copy you filed on the day you deployed is worth more than any argument you can make from memory later.

Need a second pair of eyes on an Oracle migration to AWS?

Most of the expensive mistakes here happen before anything is built, in the assumptions nobody wrote down. Things I can help with:

• Auditing feature and option pack usage on your existing databases so you know your real entitlement position before you size anything
• Working through the sysdba and host-access requirements of packaged applications to determine whether RDS is even on the table
• Modelling Processor counts across candidate instance shapes, including standby and Multi-AZ exposure, so the number in the business case survives review
• Building the operational layer that self-managed Oracle on EC2 needs: RMAN to S3, tested restores, Data Guard apply-lag alerting, and patch runbooks
• Planning migrations off RDS Custom for Oracle to EC2 ahead of the end-of-support date
• Setting up monitoring and cost attribution that separates the AWS line from the Oracle line, so finance gets an answer instead of a total

Send me the output of your feature usage query, or a list of the instance classes you are considering, and I will tell you what I would check first.

The post Oracle on EC2 vs RDS: Why the License Math Doesn’t Save You appeared first on John Nessime.

They’re right. The database is fine. That’s exactly why this incident drags on for an hour instead of ten minutes.

Connection pool exhaustion on AWS is rarely a capacity problem. It’s a queueing problem, and the queue forms in one of three places: inside your application’s pool, at the database’s connection limit, or inside a proxy sitting between the two. Each layer has its own limit, its own error message and its own fix. Resizing the instance fixes none of them reliably, and sometimes makes one worse.

Below: how to tell which layer ran out, the SQL and metrics that prove it, and fixes that survive the next deploy. Examples use RDS and Aurora for PostgreSQL and MySQL, plus HikariCP, SQLAlchemy and node-postgres where their defaults matter.

First question: which layer ran out?

Before touching anything, figure out where requests are waiting. The error text usually tells you, if you read it literally instead of pattern-matching on “connection”.

• The application pool is empty. The error comes from your pool library, not the database. HikariCP says the connection is not available and the request timed out. SQLAlchemy raises a QueuePool limit ... reached timeout. The database never saw these requests at all.
• The database refused new connections. The error comes from the server. PostgreSQL returns a FATAL about too many clients or about the remaining connection slots being reserved (the exact wording varies by major version). MySQL returns error 1040, Too many connections.
• The proxy is holding the queue. With RDS Proxy in the path, clients connect fine but wait for a database connection to be borrowed, then time out after the proxy’s borrow timeout.

Then compare what the database is actually holding against its limit. On PostgreSQL:

SHOW max_connections;

SELECT count(*) AS client_connections
FROM pg_stat_activity
WHERE backend_type = 'client backend';

On MySQL, Max_used_connections is the high-water mark since the last restart, which is useful when the spike has already passed:

SHOW VARIABLES LIKE 'max_connections';
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

If the app is throwing pool timeouts while the server is well under its limit, you’re in the first failure family. If the server is at the limit, it’s the second. That single comparison saves you from the most common wrong move, which is raising max_connections when the database was never the bottleneck.

Pool exhaustion with an idle database: the one that hides

This is the failure that fools people, because every database graph looks healthy while the application is effectively down.

A pool hands out a fixed number of connections per process. A request borrows one, and nobody else can use it until it’s returned. The pool doesn’t care whether the request is running SQL during that time. If your code opens a transaction, runs a query, then calls a payment API, uploads to S3 or sends an email before committing, the connection sits borrowed and idle for the whole round trip.

Now let that third-party API slow down. Each request holds its connection longer, the pool drains, new requests queue for a connection, and they time out. The database sees a handful of sessions doing nothing. CPU drops, because less SQL is running than usual. The dashboard gets greener as the outage gets worse.

So a slow dependency that has nothing to do with the database can exhaust your database pool, and database metrics will never show it.

Prove it with pg_stat_activity

Group sessions by state and by who owns them. The state column is the evidence; idle in transaction means a client opened a transaction and then went quiet without committing.

SELECT state,
       application_name,
       count(*) AS sessions,
       max(now() - xact_start) AS oldest_transaction
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY state, application_name
ORDER BY sessions DESC;

Then list the worst offenders. The query column shows the last statement the session ran, not what it’s doing now, which is exactly what you want here: it tells you where in the code the transaction was left open.

SELECT pid,
       application_name,
       client_addr,
       now() - xact_start AS transaction_age,
       left(query, 80) AS last_statement
FROM pg_stat_activity
WHERE state = 'idle in transaction'
ORDER BY xact_start;

On MySQL, open transactions live in information_schema.INNODB_TRX. The thread ID joins back to the process list so you can see the host and user:

SELECT trx_mysql_thread_id, trx_started, trx_state
FROM information_schema.INNODB_TRX
ORDER BY trx_started;

One thing makes all of this much faster: set application_name per service in the connection string. Without it, every session looks the same and you’re guessing from IP addresses that change with every task restart.

Leak or slow holder?

Two different bugs produce the same symptom. A leak is a code path that borrows a connection and never returns it, usually an exception path that skips the close. A slow holder returns the connection eventually but keeps it through non-database work.

The tell is recovery. Leaks never recover without a restart; the pool ratchets down one connection at a time until it’s empty. Slow holders recover when the slow dependency recovers. If restarting the service “fixes” the incident every few days, suspect a leak.

HikariCP has leakDetectionThreshold, which is off by default. Set it to a value longer than your slowest legitimate request, and it logs the stack trace of wherever a connection was borrowed and held past that threshold. That stack trace is usually the whole diagnosis. Other pools have their own hooks; if yours doesn’t, log borrow duration yourself around the checkout.

Fixes that actually hold

1. Stop holding connections across network calls. Do the external call first, then open the transaction, write, and commit. If you need the call’s result inside the transaction, restructure so the transaction is short. This is the real fix; everything else is a guardrail.
2. Put a server-side ceiling on idle transactions. PostgreSQL’s idle_in_transaction_session_timeout terminates a session that sits idle inside a transaction past the limit. The app will see an error, and that’s the point: a loud failure beats a silent pool drain. You can set it in the parameter group or scope it to the application role.
3. Fail fast on checkout. A web request that waits 30 seconds for a connection is worse than one that fails in two. Match the pool’s acquisition timeout to what the caller will tolerate.

ALTER ROLE app_user SET idle_in_transaction_session_timeout = '60s';

The role-level setting applies to new sessions for that role, so existing pooled connections keep the old value until they’re recycled. Pick a limit comfortably above your longest legitimate pause, or you’ll kill batch jobs that were behaving.

MySQL has no direct equivalent. wait_timeout closes idle sessions, but it’s a blunt setting that also affects pooled connections sitting legitimately idle, so tune it alongside your pool’s own idle and max-lifetime settings rather than instead of fixing the code.

Watch the node-postgres default specifically. Its pool connectionTimeoutMillis defaults to 0, which means no timeout: when the pool is empty, requests wait forever. You don’t get an error to alert on; you get hung requests and upstream timeouts that point everywhere except the pool.

Server slots run out while CPU idles

The second family is the one people expect: the database refuses connections. The surprise is that it happens at low CPU, and that the cause is arithmetic, not load.

Pool multiplication

Every pool size is per process. The number the database actually faces is the product of everything that opens a pool:

worst case = pool size
           x worker processes per container
           x containers at the autoscaler's maximum
           x 2 during a rolling deploy (old and new running together)
           + cron jobs, migrations, BI tools, admin sessions

Take an illustrative case: a pool of 10, four worker processes per ECS task, 30 tasks at the scaling maximum. That’s 1,200 potential connections before a deploy briefly doubles it. Nobody chose that number. It emerged from three settings owned by three different people, and it only shows up on the day traffic and a deploy coincide.

Use the autoscaler’s maximum, not today’s task count. Today’s count is what makes the math look safe.

The limit moves when you resize

On RDS and Aurora, the default max_connections in the parameter group is a formula based on the instance class’s memory, not a fixed number. So a rightsizing exercise that drops the instance a size to save money also quietly lowers the connection ceiling. The CPU graph said it was safe. The connection budget didn’t get a vote.

Don’t calculate the value by hand; the memory figure RDS uses excludes what its own processes consume. Run SHOW max_connections on the actual instance, and re-run it after every class change.

Why raising max_connections is the wrong reflex

You can override max_connections in a custom parameter group, and sometimes a modest bump is fine. But it treats the symptom. Each PostgreSQL connection is a separate backend process with its own memory, and sorts or hashes inside it can each use up to work_mem. Thousands of connections all trying to work at once contend for the same CPU cores, and throughput often drops as concurrency rises past what the hardware can run in parallel.

Also keep in mind that the last few slots are reserved for administrative roles. The application starts failing before the counter reaches the limit, and when it does, you may struggle to get your own session in to diagnose it. Keep headroom for humans.

Budget connections on purpose

1. Read the real max_connections from the instance and subtract a margin for admin sessions, monitoring agents and migrations.
2. List every consumer: each service, its worker count, its scaling maximum, and its batch jobs.
3. Divide the budget and set each pool’s maximum from that, including the deploy overlap.
4. Cap the autoscaler maximum at something the database can serve. An autoscaler that can add tasks faster than the database can accept connections just converts a traffic spike into a connection storm.
5. If the budget can’t cover the fleet, add a pooler in front instead of more slots.

Smaller pools feel scary, but a connection is only useful while SQL is running. A small pool with short transactions usually beats a large pool with long ones.

Zombie connections

Some slots belong to clients that are gone. A container killed without a clean shutdown, or a Lambda execution environment frozen between invocations, can leave server-side sessions open until something times them out. With Lambda, each concurrent environment holds its own connection, so cap concurrency and put a pooler in front; the serverless API work I do starts exactly there.

For long-lived services, set the pool’s idle timeout and max lifetime below any idle timeout on the network path, so connections are retired by the pool rather than cut silently in the middle.

When the proxy becomes the queue

RDS Proxy is the managed answer to pool multiplication. Many client connections share a smaller set of database connections, and the proxy hands a database connection to a client per transaction. When that works, the server-side limit stops being your problem.

It stops working in two ways. First, pinning: when a session changes state the proxy can’t safely share, such as setting a variable on PostgreSQL, the proxy ties that client to one database connection until the session ends. Enough pinned sessions and the proxy behaves like no proxy at all. Second, the borrow queue: when every database connection the proxy is allowed to open is busy, clients wait up to ConnectionBorrowTimeout (120 seconds by default) and then fail. Your application sees slow requests, not refused connections, and the database graphs look calm again.

The proxy’s own CloudWatch metrics tell you which it is. DatabaseConnectionsCurrentlySessionPinned shows pinning. DatabaseConnectionsCurrentlyBorrowed against DatabaseConnections shows how close the proxy is to its share of the database. And MaxConnectionsPercent on the target group caps that share as a percentage of max_connections, so a conservative setting there creates the borrow queue by itself.

The proxy is billed on the capacity of the database behind it (per vCPU-hour for provisioned instances, per ACU-hour for Aurora Serverless), so run your current rates through something like the AWS Cost Estimator before assuming it’s free relief. PgBouncer in transaction mode on a small EC2 instance is the self-managed alternative: cheaper to run, but it’s one more thing to patch, monitor and make highly available.

Metrics that warn you before connection pool exhaustion

Database CPU is the wrong alarm for this problem. By the time connection pressure shows up there, if it ever does, users already noticed. The signals that lead are on the client side:

• Threads waiting for a connection. HikariCP exposes pending threads, active and idle counts, and acquisition time through its Micrometer integration. Sustained pending threads above zero is the earliest reliable warning you get.
• Connection acquisition time. Healthy pools hand out connections almost instantly. A rising acquisition time is the queue forming, long before timeouts start.
• Server connections as a ratio of the limit. Alarm on CloudWatch DatabaseConnections relative to the instance’s real max_connections, not an absolute number that goes stale after a resize.
• Oldest open transaction. A scheduled query against pg_stat_activity exporting the age of the oldest xact_start catches slow holders and leaks early.

Where these land matters less than having them next to each other. Grafana with a Prometheus scrape of the application’s pool metrics works well, as do Datadog or New Relic APM, which can show pool wait time inside the request trace. Sentry is useful for grouping the pool-timeout exceptions so you see the first one, not the thousandth. The goal is one screen where app pool state and database connection counts share a time axis. If you’d rather not build that, it’s the kind of thing covered under AWS monitoring and alerting.

Troubleshooting by symptom

• Pool timeouts, database far below its limit, many idle-in-transaction sessions: slow holder or leak. Find the last statement in pg_stat_activity and trace the code path that follows it.
• Pool timeouts, few database sessions at all: the pool is too small for the worker count, or connections are borrowed and held without a transaction open. Check borrow duration, not the database.
• Refused connections only during deploys: the old and new versions overlap. Budget for the overlap or slow the rollout.
• Refused connections right after an instance class change: the formula-derived limit dropped. Check SHOW max_connections.
• Requests hang with no error at all: a pool with no acquisition timeout, such as node-postgres at its default. Set one.
• Everything was fixed by a restart, then came back days later: a leak. Turn on leak detection and wait for the stack trace.
• RDS Proxy in the path, slow requests, calm database: check pinned and borrowed connection metrics before anything else.

Common mistakes

• Scaling the instance up because “it’s the database”, when the database was idle the whole time.
• Raising max_connections to absorb pool multiplication, then losing throughput to contention.
• Making the pool bigger to fix pool timeouts caused by long transactions. It buys minutes and moves the failure to the server limit.
• Sizing pools from today’s task count instead of the autoscaler’s maximum.
• Adding RDS Proxy without checking pinning, and ending up with a paid queue instead of a pool.

Best practices

• Keep transactions short and never hold a connection across an external call.
• Write the connection budget down, with every consumer, and revisit it when scaling limits or instance classes change.
• Set an acquisition timeout that matches what callers will tolerate, and alert on pending threads, not on timeouts.
• Use idle_in_transaction_session_timeout on PostgreSQL as a safety net, scoped to application roles.

FAQ

What causes connection pool exhaustion when database CPU is low?

Usually connections held while no SQL runs: long transactions, external API calls inside a transaction, or leaked connections that were never returned. The pool is empty, but the database is doing very little.

Should I increase max_connections on RDS?

Only after confirming the server limit is actually the one being hit, and only modestly. If the cause is pool multiplication, budget the pools or add a pooler. More connections means more memory per backend and more contention, not more throughput.

How big should my connection pool be?

Smaller than most people set it. Start from the connection budget divided across every process at maximum scale, then load test. A pool large enough to cover every thread usually just moves the queue from the application to the database.

Does RDS Proxy fix pool exhaustion?

It fixes server-side slot exhaustion from many clients, as long as sessions aren’t pinned. It does nothing for an application pool drained by long transactions, because those transactions hold the proxy’s database connections just as firmly.

How do I find leaked connections in PostgreSQL?

Look for sessions in pg_stat_activity that stay idle or idle in transaction for far longer than any request should, grouped by application_name. Then turn on your pool’s leak detection to get the stack trace of where the connection was borrowed.

Does this happen on self-hosted databases too?

Exactly the same way. On PostgreSQL running on a VPS from providers like Hetzner, Contabo or InterServer, the pool math and idle transactions behave identically; the difference is that you run PgBouncer yourself instead of paying for RDS Proxy.

Conclusion

Connection pool exhaustion on AWS almost never means the database is too small. It means a queue formed somewhere, and the fix depends entirely on where. Read the error literally, compare the database’s connection count against its real limit, and within minutes you’ll know if you’re dealing with a drained application pool, a server limit reached by arithmetic, or a proxy holding the line.

If you remember one thing: a connection costs you for as long as it’s borrowed, not for as long as SQL runs. Shorten the borrow and most of these incidents stop happening.

Need help tracking down a connection problem on AWS?

This is work I do for teams running RDS, Aurora or self-managed PostgreSQL and MySQL. Typical engagements look like this:

• Working out which layer is exhausting during an incident, from pool logs, pg_stat_activity and CloudWatch.
• Building a written connection budget across services, workers, autoscaling limits and deploy overlap.
• Finding leaks and long-held connections in application code, with leak detection and transaction timeouts set sensibly.
• Evaluating RDS Proxy or PgBouncer for your workload, including pinning and cost.
• Dashboards and alerts that put application pool state and database connections on the same screen.
• Checking what an instance resize will do to your connection limit before you make it.

Send me the pool timeout from your logs and the output of the pg_stat_activity query above, and I’ll tell you which layer ran out.

The post Plenty of CPU, Zero Connections: Debugging Connection Pool Exhaustion on AWS appeared first on John Nessime.

The part that hurts you later is not on that page.

The AWS Schema Conversion Tool for Oracle grades syntax. It tells you whether it could emit valid PostgreSQL for an object. It does not tell you whether that object will behave the same way at runtime. A trigger can convert with a green tick and fire in a different order. A column can convert with a green tick and silently drop the time component off every date in the table. A procedure can convert with a green tick and run twenty times slower because every string function call now goes through a wrapper.

This post sorts the tool’s output into four buckets: what converts cleanly, what converts while quietly changing meaning, what converts only through the extension pack, and what it refuses outright. Then the category nobody budgets for, which is everything it never looks at.

What the AWS Schema Conversion Tool for Oracle actually does

It is a Java desktop application. It connects over JDBC to source and target, reads the Oracle data dictionary, parses the DDL and PL/SQL it finds, and generates equivalent PostgreSQL objects and PL/pgSQL. The converted code stays inside the project until you explicitly apply it to the target or save it out as SQL files.

Three things follow from that description, and they matter more than any feature list.

• It only sees what is stored in the database. Code that lives in your application, your job scheduler, or a reporting tool is invisible to it unless you point the separate application SQL conversion feature at those files yourself.
• It only sees what the connecting user can see. Connect with a thin account and half the schema will not appear in the report at all.
• It moves structure and code. It does not move rows. That is AWS DMS, and it is a separate exercise with its own failure modes.

There is also a command line interface, which is the part most teams discover too late. It uses scenario files rather than flag-style arguments, and it needs Amazon Corretto 11 installed alongside the tool.

# Interactive mode, run from the AWS SCT app folder.
# End each command with a / on its own line.
java -jar AWSSchemaConversionToolBatch.jar -type interactive

# Script mode, running a saved .scts scenario end to end.
java -jar /opt/aws-schema-conversion-tool/lib/app/AWSSchemaConversionToolBatch.jar 
  -type scts -script /home/sct/project/convert.scts

Script mode turns a one-off conversion into something you can rerun, which matters because on a real migration you will convert the schema many times as you clean up the source. Re-clicking through the GUI each time is how mistakes creep in.

Tier one: converts cleanly, and you can trust it

Credit where it is due. For the bulk of an ordinary OLTP schema the tool is good, and hand-writing this would be miserable.

• Table definitions: names, columns, ordinary data types, NOT NULL, defaults, primary keys, unique constraints, foreign keys.
• Standard b-tree indexes, including most single-column functional indexes.
• Ordinary views. The basic CREATE VIEW syntax is close to identical between the two engines.
• Sequences and identity columns, despite the syntax looking nothing alike.
• ANSI-standard SQL, joins, subqueries, and almost all window and analytic functions.
• PL/SQL flow control: loops, blocks, conditionals, exception structure.
• The four standard transaction isolation levels, plus BEGIN, COMMIT, and ROLLBACK.

If your schema is mostly tables, views, and reporting SQL with modest procedural code, the automation figure in the report is roughly honest and you should believe it.

Tier two: converts green, behaves differently

This is the tier that costs money, because none of it shows up as a red action item. The object converted. The DDL applied. The application connected. Something is wrong three weeks later and nobody thinks to look back at the schema conversion.

Oracle DATE is not PostgreSQL date

Oracle’s DATE type carries a time component down to the second. PostgreSQL’s date is a calendar day and nothing more. Map an Oracle DATE to a PostgreSQL date and every timestamp in that column is truncated, permanently, without an error. The correct target is timestamp. Check the conversion settings and check the generated DDL before you apply, because this one is not recoverable after the data lands.

NUMBER without precision becomes numeric, and numeric is slow

An unqualified Oracle NUMBER is an extremely flexible container, so the default mapping to PostgreSQL numeric is technically correct. It is also arbitrary-precision arithmetic implemented in software. Put that on a surrogate key that participates in every join and index in your application and you have bought yourself a performance problem that no amount of index tuning will fix.

Find the candidates before conversion, not after:

-- Oracle: unqualified NUMBER columns, the ones that default to numeric.
SELECT table_name, column_name, data_precision, data_scale
FROM   user_tab_columns
WHERE  data_type = 'NUMBER'
AND    data_precision IS NULL
ORDER  BY table_name, column_name;

For each one, look at the actual minimum, maximum, and scale of the data, then decide whether it is really an integer, a bigint, or a genuine numeric(p,s). Surrogate keys and foreign keys are almost always integers pretending to be NUMBER. Money columns usually are not.

Empty string is NULL in Oracle and is not in PostgreSQL

This is the single most reliable source of post-cutover bugs, and it is not a conversion defect. Oracle treats an empty string as NULL. PostgreSQL treats it as a zero-length string, which is a real value. Every IS NULL check in your procedural code and your application was written under Oracle’s rule.

Concatenation flips too. In Oracle, concatenating a NULL is a no-op. In PostgreSQL, concatenating a NULL with the || operator yields NULL for the whole expression. A report that used to print a name with a missing middle initial now prints nothing at all.

After the data lands, count the divergence before you let users near it:

-- PostgreSQL: how many rows are empty string rather than NULL?
SELECT count(*) FILTER (WHERE middle_name = '')   AS empty_string,
       count(*) FILTER (WHERE middle_name IS NULL) AS real_null
FROM   app.customer;

If empty_string is non-zero anywhere, you have a decision to make: normalize the data on load, or audit every NULL check that touches those columns. Normalizing is usually cheaper and is far easier to verify.

The warnings the tool does raise, that people scroll past

Some of these semantic differences do appear in the action list, just not in red. They are worth reading individually rather than in aggregate.

• GREATEST and LEAST are flagged as potentially producing different results from the source, because of how each engine handles NULL arguments and type coercion.
• Timestamp handling inside converted partitioned tables is flagged as potentially divergent.
• Converted code is flagged as possibly incorrect where bind variable names, user-defined functions, or dynamic SQL are involved. That is the tool telling you it guessed.
• Trigger firing order is not carried over. Oracle’s FOLLOWS and PRECEDES clauses have no equivalent, and PostgreSQL fires triggers on the same event in alphabetical order by trigger name. If your Oracle triggers depended on sequencing, you now depend on naming.
• An empty exception block in the converted output is called out explicitly. Oracle code that swallowed errors will now swallow them differently.

One more that is not an action code at all: Oracle PL/SQL routinely issues COMMIT in the middle of a procedure. A PostgreSQL function cannot do that. Either the logic becomes a procedure invoked with CALL, or the transaction boundary moves out into the calling application. That is a design decision, not a find-and-replace.

Tier three: converts, but only through the extension pack

When there is no native PostgreSQL equivalent for something Oracle provides, the tool installs an extension pack: an additional schema on the target, named aws_oracle_ext for Oracle sources, containing wrapper functions, tables, and supporting objects that emulate the source behavior. For some capabilities like job scheduling and sending mail, the pack also deploys AWS Lambda functions.

So a call to INSTR in your PL/SQL comes out the other side as aws_oracle_ext.INSTR. Package variables, which have no PostgreSQL equivalent because PL/pgSQL has no packages, get routed through getter and setter functions in the pack.

The case for accepting this is real. If the goal is off Oracle licensing by a fixed date, the pack converts code that would otherwise need a developer per object. That is the difference between a migration that ships and one that stalls in refactoring, and nobody gets a bonus for elegant PL/pgSQL on a project that missed its window.

The case against is equally real:

• Wrapper functions sit between your code and the engine. In hot loops, that overhead is measurable, and the package-variable emulation in particular is not free.
• You have swapped one dependency for another. The pack is AWS-specific code living in your database, which is an awkward thing to explain if the stated goal was ending vendor lock-in.
• Every time the pack is applied, its components are overwritten. Anything you hand-tuned inside that schema is gone.
• Upgrades and target-version changes now have an extra moving part to validate.

There is a middle path. The tool can be configured to use the open-source orafce extension, which implements a subset of Oracle functions and packages natively in PostgreSQL, in place of some pack wrappers. My rule of thumb: use the pack to get the migration over the line, then treat the size of the aws_oracle_ext call graph as a debt register you burn down deliberately, starting with whatever appears in your slowest queries. Rewriting collections as native arrays or JSON, and package variables as parameters, buys back most of the performance.

Tier four: it stops and hands you the work

These are the red items: the honest part of the report, and paradoxically the least dangerous, because you can see them and plan around them. Not exhaustive, but this is what turns up on real Oracle schemas.

• Database links. No automation at all. The mechanism has to be rebuilt, usually on postgres_fdw, and foreign data wrappers do not support calling user-defined functions on the remote side. If your architecture leans on links, this is a workstream, not a task.
• Autonomous transactions. PostgreSQL has no direct equivalent. Logging patterns that relied on committing independently of the parent transaction need redesign, often with dblink back to the same instance or an out-of-band queue.
• ROWID and UROWID. No equivalent, and any code that reads ROWID from a table is flagged separately. Row-identity tricks in PL/SQL are a rewrite.
• Dynamic SQL and DBMS_SQL. Anything assembled at runtime the parser cannot resolve statically comes back untouched or with a health warning.
• Synonyms. Not supported, and neither is their usage, so every reference through a synonym has to be resolved by hand or mimicked with views and search paths.
• Global temporary tables, index-organized tables, external tables, clustered tables, object tables, nested tables, virtual columns, BFILE. Storage and type features with no target equivalent.
• Bitmap indexes, domain indexes, multi-column functional indexes. The first two have no counterpart; the third is a documented conversion gap.
• Associative arrays, VARRAY of VARRAY, multi-dimensional arrays, object type methods, member functions in user-defined types. Collection-heavy PL/SQL is where the automation percentage collapses.
• Compound triggers, system triggers, REFERENCING clauses, conditional predicates. The trigger model differs enough that anything beyond a plain row trigger needs attention.
• Java stored routines and table functions. Not converted.
• Query hints. Partially converted, and you should delete them all first anyway. Hints tuned for Oracle’s optimizer are noise to a different planner. Add them back only after schema, index, and query work have failed.
• Materialized view incremental refresh and DML on materialized views. The view itself may convert; the refresh strategy will not.

Some red items are more conservative than your actual target

Here is a detail that saves real budget. The action code index and the migration playbook were written against a baseline target, and PostgreSQL has moved since. MERGE is listed as unsupported, but PostgreSQL has had a native MERGE statement since version 15. FOR UPDATE SKIP LOCKED is listed as unsupported, and it has been in PostgreSQL for a long time. GROUPING SETS, CUBE, and ROLLUP are listed as unsupported and are also long-standing PostgreSQL features.

What this means practically: an action code tells you the converter will not emit the construct for you. It is not a statement about your target engine. Before you scope a rewrite for anything on that list, check the feature against the PostgreSQL version you are actually deploying. Some of those “rewrites” are a copy-paste with a syntax tweak.

What it never looks at

This is the category that wrecks timelines, because it is not in the report at all. Not green, not red. Out of scope, therefore invisible.

• Application code. There is a separate application SQL conversion feature that scans source files for embedded SQL, but it is opt-in, file-based, and you have to aim it. Nothing happens automatically.
• Scheduled work. DBMS_SCHEDULER jobs, cron entries calling SQL*Plus, shell wrappers, ETL controllers. The schema converts; the thing that runs it every night does not.
• Grants, roles, profiles, and proxy authentication. Your security model is a separate design exercise on the target.
• Oracle features with no schema footprint. Data Guard, RAC, ASM, RMAN, Oracle Text indexes, fine-grained access control policies. Each is its own replacement decision.
• Optimizer statistics and execution plans. Nothing about performance carries over. You are starting from zero on the target, and that is the right expectation to set with stakeholders early.
• Everything downstream. BI dashboards, reporting layers, and integration jobs that embed Oracle-flavored SQL will break on the day you cut over, and none of them appear in the assessment.

Inventory these before conversion, not after. A one-page list of every consumer of the schema is worth more than a week of tuning.

Desktop tool or DMS Schema Conversion?

DMS Schema Conversion is the managed, browser-based version built on the same engine. Instead of a laptop install you create an instance profile, register source and target data providers with credentials in Secrets Manager, and run the project from the console, with metadata staged in S3.

AWS now points standard OLTP conversions at the managed option, and generative AI assisted conversion is available there on supported paths. The desktop tool remains available and still covers ground the managed feature does not.

• Pick the desktop tool when you need scripting through the CLI, want to edit the SQL for source and target inside the project, need migration rules and tree filters, are converting a data warehouse target, or want the application SQL and ETL conversion features.
• Pick DMS Schema Conversion when your source is reachable from a VPC, you would rather not manage a workstation with database credentials on it, your conversion path and region are supported, and the generative AI assist is useful to you.

Check supported paths, versions, and regions before committing either way; they differ between the two. On the desktop side, note the supported operating systems are Windows, Fedora, and Ubuntu, all 64-bit. If your analysts are on Macs, plan for a Linux jump box. A small VPS from a provider like Contabo or InterServer, or an EC2 instance inside the VPC, is the usual answer, and it has the side benefit of keeping the JDBC connection close to the source rather than dragging a dictionary read across a home broadband link.

If the Oracle source is on-premises and the conversion box is not, you need a network path that a DBA will sign off on. That is normally a site-to-site VPN or Direct Connect. For an individual consultant working against a client’s staging environment, a commercial VPN such as NordVPN or Surfshark is sometimes what is on offer, but treat it as a stopgap: it gets you connectivity, not an audit trail.

Troubleshooting

The CLI jar refuses to open

A common failure is an unexpected error opening AWSSchemaConversionToolBatch.jar. Recent OpenJDK builds cap the size of jar signature files and the SCT jar exceeds the default. Raising that limit on the java invocation is the widely reported workaround:

java -Djdk.jar.maxSignatureFileSize=20000000 
  -jar AWSSchemaConversionToolBatch.jar -type interactive

Confirm you are on the Corretto 11 runtime the tool expects before chasing anything more exotic.

It hangs on a large schema, or will not connect at all

Thousands of objects in one schema puts the JVM under memory pressure; Global settings exposes JVM options, so raise the heap and retry on a machine with real memory. Separately, JDBC driver paths live in Global settings under Drivers, per engine. A driver sitting on disk but not registered there fails in a way that looks like a network problem and is not.

“The package body doesn’t include source code”

The source is wrapped. Obfuscated PL/SQL cannot be parsed, so it cannot be converted. Either find the original in version control or accept a from-scratch rewrite. Finding this on a critical package late in the project is a bad day, so check for wrapped objects on day one.

Objects will not apply, or the report is missing things

Failures on apply are usually dependency order: an object references a parent that was not converted or sits outside the schema mapping, and the action list says so explicitly. Convert the whole dependency closure, not just the objects you care about. A short report is usually privileges, since the tool reads through the connecting account’s visibility. Compare its object counts against a direct dictionary count before trusting any percentage in it.

Common mistakes

• Treating the automation percentage as a completion estimate. It measures objects, not effort, and one gnarly package can outweigh four hundred clean tables.
• Applying to the target before reviewing the generated DDL. Save to SQL, read it, diff it on the next run.
• Accepting default type mappings wholesale. DATE and unqualified NUMBER are the two that reliably hurt.
• Carrying Oracle hints across. Start with none and earn each one back.
• Scoping rewrites straight off the action codes without checking your target PostgreSQL version first.
• Leaving project files and scenario scripts containing database credentials sitting on a laptop after the engagement. They are plain files; when the work is done, wipe them properly with a tool like O&O SafeErase rather than dragging them to the trash.

Best practices

1. Connect with an account that can see the whole schema, then verify object counts against the dictionary before reading any percentage.
2. Profile your NUMBER and DATE columns first and set the type mappings deliberately. Do this before the first conversion, not after the first load.
3. Script the conversion with the CLI so every run is identical and reviewable.
4. Sort red action items by object criticality, not by count. Twenty flags on a nightly batch job matter more than two hundred on a deprecated reporting view.
5. Write the semantic test suite before cutover: empty string versus NULL, date boundaries, numeric rounding, trigger ordering, transaction behavior in converted routines.
6. Instrument the target from day one. Query-level metrics in Amazon CloudWatch, or a Grafana stack against pg_stat_statements, will show you which extension pack wrappers are actually costing you before users complain.

Frequently asked questions

Is the AWS Schema Conversion Tool free?

The tool itself is a free download from AWS. What you pay for is everything around it: the compute you run it on, the target database, DMS replication instances for the data move, and the engineering time on the objects it hands back to you. That last item is the whole budget on most migrations.

Does it migrate data as well as schema?

No. It converts structure and code. Moving rows is AWS DMS, which handles both a full load and ongoing change capture. They are designed to be used together, and each has its own set of behaviors worth understanding separately.

Can I skip the extension pack entirely?

You can, but you are then hand-writing PostgreSQL equivalents for every Oracle built-in the pack would have covered. Configuring the tool to prefer orafce where possible is the usual compromise: fewer AWS-specific wrappers, open-source implementation, still automated. Full independence is achievable and is a refactoring project, not a setting.

Why did my report say 95% automatic and the project still take months?

Because the percentage counts objects, ignores runtime semantics entirely, and excludes application code, scheduled jobs, security, and downstream consumers. Tier two and the out-of-scope list in this post are where the months go.

Should I clean up the Oracle schema before or after conversion?

Before, every time. Dropping dead objects, unwrapping code you own, and removing synonyms on the source reduces the surface the tool has to reason about and shrinks the red list. It is also the only cleanup you can do while you still have a working system to test against.

How do I verify the conversion actually worked?

Row counts and DDL comparison are the floor, not the ceiling. Run the same business queries against both engines and compare results, with deliberate coverage of NULL handling, date boundaries, sorting and collation, and numeric rounding. Anything that only shows up under concurrency needs a load test, not a smoke test.

The one thing worth remembering

The AWS Schema Conversion Tool for Oracle is a good parser and an honest one about the things it cannot parse. The red list is trustworthy. The trouble is that a green tick means “I emitted valid PostgreSQL,” not “this behaves the way it did.” Dates lose their time, unqualified NUMBER lands as slow arithmetic, empty strings stop being NULL, triggers reorder themselves alphabetically, and none of that appears as a problem in the report.

Use it for what it is good at, which is the tedium you should never do by hand. Then spend your review time on the objects that passed, because that is where the expensive surprises live. Treat the assessment report as an inventory, never as a schedule.

Need a second pair of eyes on an Oracle to PostgreSQL conversion?

Most of the value in this work is in the review, not the click. Things I help with:

• Reading an assessment report properly: separating object counts from real effort, and re-scoping red items against the PostgreSQL version you are actually deploying.
• Auditing type mappings before you apply, with a column-level profile of NUMBER and DATE usage and a concrete mapping decision for each.
• Building the semantic test suite that catches empty-string and NULL divergence, trigger ordering, and rounding differences before users find them.
• Scripting the conversion through the SCT CLI so it is repeatable, reviewable, and lives in version control alongside the generated DDL.
• Planning the extension pack burn-down: which aws_oracle_ext calls are costing you, and what the native PostgreSQL replacement looks like.
• Mapping the out-of-scope surface, meaning scheduled jobs, grants, downstream reports and integrations, so cutover day has no surprises in it.

Send me an assessment report, a converted DDL file, or the action item list, and I will tell you what I would actually worry about in it.

The post AWS Schema Conversion Tool for Oracle: What Converts and What Quietly Doesn’t appeared first on John Nessime.

That argument settles architecture decisions all the time, and it’s the wrong argument. Both services return a primary-key lookup faster than your network hop and your ORM overhead. What hurts six months later is the query nobody wrote down at the start, and no benchmark will warn you about it.

So this post skips the latency charts. It covers the access pattern inventory you write before picking anything, where each service genuinely wins and genuinely hurts, a decision procedure you can run in an afternoon, and the arguments on both sides that fall apart on contact with a real workload.

Why the benchmark answers a question you don’t have

A benchmark measures a fixed operation under fixed conditions. Your application is not a fixed operation. It’s a set of reads and writes that grows every time somebody asks a new question about the data.

The failure mode that decides RDS vs DynamoDB is almost never throughput. It’s a product manager asking, eight months in, for every account that hasn’t logged in this quarter, broken down by plan tier. On Postgres that’s an awkward query and maybe an index. On DynamoDB, if you didn’t model for it, it’s a full table scan, a new global secondary index, a backfill, and a standing write-capacity tax to keep it in sync.

That asymmetry is the whole decision. A relational database defers the modeling cost and charges a little on every query for the flexibility. DynamoDB front-loads it: design keys around known patterns, get cheap predictable reads for exactly those, and pay dearly for anything else.

Write the access pattern inventory first

Before comparing anything, write the list. Every read and write the application performs, in plain language, with the shape of the operation and how fast it needs to be. This much is enough:

PATTERN                                SHAPE           FREQ    LATENCY
get order by id                        point read      high    p99 < 50ms
list a customer's orders, newest first range read      high    p99 < 100ms
orders by status, across customers     cross-entity    low     seconds fine
revenue by product category, monthly   aggregate       low     minutes fine
find orders by partial address         text match      medium  p99 < 300ms
mark order shipped + write audit row   multi-item write high   p99 < 100ms

Now read the SHAPE column. If nearly every row is a point or range read, and the exceptions tolerate latency, DynamoDB is a live option. If the column is full of cross-entity reads, aggregates and text matching, you’re describing a relational workload and can stop shopping.

The rows people leave out

The inventory is only useful if it’s honest, and the omissions are predictable:

• The admin back office. Support staff search by email, phone, partial name, anything. Ad hoc queries, and they never appear in the first inventory.
• Reporting. Someone will want a monthly rollup. Decide now whether it lives in the operational store or streams out to a warehouse.
• Deletion. Regulatory deletes cascade across entities. In a normalized schema that’s a transaction. In a denormalized single table it’s a fan-out you have to write and test yourself.
• Backfills. Every schema change becomes a migration job when no schema is enforced at the storage layer.

Write them down even if the answer is “we’ll handle it elsewhere.” A pattern you consciously exile to a warehouse is fine. One you forgot is a rewrite.

Where DynamoDB wins, and where it doesn’t

Give it its genuine case first, because it’s a strong one.

Where it wins

• Connection model. It’s an HTTPS API with SigV4 auth, so there’s no pool to exhaust. That’s why it pairs cleanly with Lambda. A relational database behind high Lambda concurrency needs RDS Proxy or a pooler, which is another component you operate.
• Predictable reads at any size. A query against a well-chosen partition key costs the same at ten thousand items or ten billion. Nothing in Postgres gives you that for free.
• Idle cost. On-demand mode bills per request unit consumed, so a table with no traffic costs storage and nothing else. Useful for tenant-per-table designs and low-traffic side services.
• Operational surface. No minor version upgrades, no vacuum, no failover window, no parameter groups to argue about.

The query API is narrow on purpose. Give it an exact partition key plus an optional sort key condition, and it returns an ordered slice of an item collection:

aws dynamodb query 
  --table-name AppData 
  --key-condition-expression "PK = :pk AND begins_with(SK, :sk)" 
  --expression-attribute-values '{":pk":{"S":"CUSTOMER#42"},":sk":{"S":"ORDER#"}}'

One customer’s orders, in sort order, in one request, no join. If that call shape covers most of your inventory, you’re looking at the right service.

Where it doesn’t

• Anything you didn’t model. New patterns mean new keys or a new index, and a new global secondary index means a backfill plus write capacity on every future write.
• Filtering is not querying. A FilterExpression runs after the read, so you pay capacity for every item examined and only save bandwidth. A filter that discards most of what it reads is a design smell.
• Aggregates. There is no GROUP BY and no COUNT(*) over a table. You maintain aggregates yourself, usually with DynamoDB Streams feeding a Lambda that updates a counter item, which means you own the correctness problem when that consumer fails.
• Hard physical limits. An item caps at 400 KB. A Query or Scan page returns at most 1 MB before you paginate. A single partition sustains roughly 3,000 read and 1,000 write units per second, so a hot key throttles while the table sits well under its quota.
• Index budget. Global secondary indexes default to twenty per table; local secondary indexes cap at five and can only be defined at table creation. You can’t index your way out of a bad key design forever.

Where RDS wins, and where it doesn’t

Where it wins

• Unknown future queries. The entire point. Joins, aggregates, window functions, ad hoc analysis, and a new index in one statement when something turns out slow.
• Constraints the database enforces. Foreign keys, uniqueness, check constraints, transactions across arbitrary tables. In DynamoDB each of those is application code you write and maintain.
• Extensions. PostGIS for geospatial, pgvector for embeddings, full-text search built in, all against the same rows in the same transaction.
• Portability. Postgres and MySQL run on RDS, in a container, or on a plain VPS from a provider like Contabo or InterServer, so migrating off is an export and an import. DynamoDB’s data model doesn’t port without rewriting your data access layer.
• Everyone already knows SQL. Underrated on a small team. Teaching four developers single-table design costs real review time.

Where it doesn’t

• Connections under serverless concurrency. Each Lambda execution environment opens its own connection, and the database refuses new ones once max_connections is reached. RDS Proxy multiplexes to fix that, but some operations pin a client to a backend connection and pinned connections aren’t reused. Watch DatabaseConnectionsCurrentlySessionPinned before trusting the pool.
• Instances are always on. A provisioned instance bills whether or not anyone queries it. Aurora Serverless v2 changes that with a minimum of zero capacity units on a supported engine version, but resuming from paused is slow enough that the first user after an idle period feels it. AWS documents resume as taking roughly fifteen seconds.
• Vertical scaling has a ceiling. Writes go to one primary and read replicas help reads only. Sharding is a project, not a setting.
• Maintenance is yours. Version upgrades, failover testing, long transactions blocking vacuum, connection storms on restart. Managed does not mean absent.

If you want a database that hibernates properly, it lives in the scaling configuration and the idle timeout is yours to set:

aws rds create-db-cluster 
  --db-cluster-identifier app-cluster 
  --engine aurora-postgresql 
  --serverless-v2-scaling-configuration 
      MinCapacity=0,MaxCapacity=4,SecondsUntilAutoPause=600 
  --manage-master-user-password

A minimum of zero only works on engine versions supporting automatic pause and resume, so check yours before planning a budget around it. If the cluster refuses the setting, that’s usually why.

A decision procedure for RDS vs DynamoDB

Run these in order against the inventory you wrote. The first clear answer wins.

1. Can you enumerate the access patterns, and are they stable? If the product is still moving and nobody can say what the admin tools will need, pick the store that tolerates being wrong. That’s RDS.
2. Does any pattern need a cross-entity aggregate on the hot path? A user-facing screen needing a count or sum across entities in under a second, with no way to precompute it, means RDS.
3. Is there a natural partition key with even distribution? Tenant ID, user ID, device ID. If traffic concentrates on one key, the per-partition ceiling finds you regardless of capacity mode. No good key means no DynamoDB.
4. What’s the concurrency shape of the compute tier? Thousands of short-lived Lambda invocations argue for DynamoDB. A few long-running containers with a warm pool remove the strongest argument against RDS.
5. Does the workload go quiet? Bursty and mostly idle favors on-demand DynamoDB or a scale-to-zero Aurora cluster. Steady traffic makes provisioned capacity or a right-sized instance cheaper.
6. Who maintains this in a year? If it’s one part-time developer, weight familiarity heavily. A design nobody on the team can debug is a liability whatever the benchmark said.

The cost model nobody actually models

The two bill on axes that don’t compare. RDS charges instance hours, storage, and depending on engine and storage type, I/O, busy or not. DynamoDB charges request units and storage, so an idle table is nearly free and a chatty one isn’t.

The number that matters is request units per user action, and almost nobody calculates it. Reads bill in 4 KB increments and writes in 1 KB increments, strongly consistent reads cost twice what eventually consistent ones do, and transactional operations double again. Every index you project into consumes write units on every write that touches it. A screen firing six queries plus an audit write can cost many times the naive estimate.

Work it out per action, multiply by real traffic, and sanity check the instance side with my AWS cost estimator before the decision hardens. AWS recommends on-demand as the default capacity mode for most workloads, but steady predictable traffic is still cheaper provisioned, and you can flip between them:

# which mode is this table on?
aws dynamodb describe-table --table-name AppData 
  --query "Table.BillingModeSummary.BillingMode"

# what is it actually consuming?
aws cloudwatch get-metric-statistics 
  --namespace AWS/DynamoDB 
  --metric-name ConsumedWriteCapacityUnits 
  --dimensions Name=TableName,Value=AppData 
  --statistics Sum --period 3600 
  --start-time $(date -u -d '1 day ago' +%Y-%m-%dT%H:%M:%SZ) 
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ)

Switching billing mode is rate limited, so treat it as a planned change rather than an incident-time knob.

Arguments that don’t survive contact

• “DynamoDB scales infinitely.” The service does. Your partition key might not. Uneven access concentrates load on one partition, and adaptive capacity only helps within limits.
• “Postgres can’t handle our scale.” Usually said before anyone has run EXPLAIN (ANALYZE, BUFFERS) on the slow query. A missing index and an N+1 in the ORM explain most claims of outgrowing relational.
• “We’ll add the indexes later.” True in Postgres, expensive in DynamoDB. A new global secondary index backfills across the whole table and then taxes every subsequent write.
• “Serverless database means no operations.” You trade instance operations for capacity and key-design operations. Throttling, hot partitions and stream consumer lag all need dashboards, exactly like a relational instance does.
• “We can just use both.” Sometimes right, often a way to avoid deciding. Two stores means two consistency models, two restore procedures, and a sync path that becomes the least reliable component you own.

How I’d decide

My default for a new application with an unfinished product definition is managed Postgres. Not because it’s better, but because being wrong about a relational schema costs an afternoon and being wrong about a key design costs a migration.

I’d reach for DynamoDB first when the workload is a small closed set of patterns keyed off one identifier, with high write volume, tolerance for eventual consistency, and concurrency that would flatten a connection pool. Session stores, telemetry ingestion, per-user feeds, idempotency keys, feature flags. It’s excellent at all of those.

The hybrid worth doing is narrow: relational as the system of record, DynamoDB for one high-volume pattern that joins nothing. The hybrid to avoid splits related entities across both stores and reconciles them in application code.

Whichever you land on, instrument it on day one. Throttled requests and consumed capacity on the DynamoDB side, connection counts and slow queries on the relational side, on a CloudWatch or Grafana Cloud dashboard someone actually opens. If you’re restricting item-level access with IAM condition keys such as dynamodb:LeadingKeys, run the policy through my IAM policy checker before it ships.

Frequently asked questions

Is DynamoDB always faster than RDS?

For a primary-key lookup at large scale its latency is more consistent, because that operation’s cost doesn’t grow with table size. For a query it wasn’t modeled for it can be far slower, because the fallback is a scan. Speed depends on the match between query and key design, not on the service.

Can I run analytics on DynamoDB?

Not directly, and you shouldn’t try. Export the table to S3 or stream changes out, then query with Athena or load a warehouse. Treat operational and analytical stores as separate systems.

What about Aurora Serverless as the middle ground?

It solves idle cost, not connections or write scaling. If you’re considering DynamoDB because of Lambda concurrency or single-primary write limits, Aurora Serverless doesn’t address that. If it’s because you’re paying for an idle dev database, it does.

How do I migrate from DynamoDB to RDS if I get it wrong?

Export to S3, reshape denormalized items into normalized tables, load, and dual-write during cutover. The data movement is routine. The hard part is that your application code assumed a key-value access shape everywhere, so the rewrite lands in the service layer, not the pipeline.

Is DynamoDB cheaper than RDS for a small application?

Usually yes when traffic is low and bursty, because on-demand charges per request against an idle table while an instance bills continuously. The advantage narrows as traffic steadies and reverses once throughput justifies provisioned capacity or a reserved instance.

Do I need RDS Proxy if I use Lambda with Postgres?

At meaningful concurrency, yes. Below that, a direct connection reused across invocations is fine, and the proxy adds cost plus a pinning failure mode. Add it when connection counts approach your limit, not preemptively in development.

Conclusion

The one thing worth remembering about RDS vs DynamoDB: you’re not choosing a performance profile, you’re choosing when to pay the modeling cost. DynamoDB takes it up front and pays you back in predictability. A relational database lets you defer it and charges interest later in query complexity.

Write the access pattern inventory. Be honest about the admin screens and the reporting nobody has asked for yet. If the list is short, stable and keyed on one identifier, DynamoDB will serve you for years. If it isn’t, take the relational database and spend the saved effort on indexes and connection handling.

Need a second opinion on the data store decision?

Cheap to review now, expensive to revisit later. Things I help with:

• Building the access pattern inventory with your team and pressure-testing it against the queries your roadmap implies
• Reviewing a DynamoDB key and index design before it ships, including partition key distribution and index write amplification
• Diagnosing throttling and hot partitions on an existing table, and whether the fix is a key change, a capacity change or a cache
• Sizing RDS or Aurora for a serverless compute tier, including connection handling, RDS Proxy configuration and pinning
• Modeling the cost of both options against your real request volume instead of a rule of thumb
• Planning a migration in either direction, with a dual-write cutover and a rollback that works

Send me your access pattern list, a slow query plan, or your throttling metrics and I’ll tell you what I’d do with it.

The post RDS vs DynamoDB: The Benchmark Isn’t the Decision appeared first on John Nessime.