AWS Database Blog
Accelerating developer productivity in the agentic AI era with Amazon Aurora PostgreSQL
The craft of building software is being rewritten in real time. A few months ago, Pravin called Elizabeth and me with a story about his son. Over a single weekend, his preteen and a couple of friends used AI-assisted coding tools to build an app in just a few hours. Pravin, who leads engineering for Amazon Aurora and has spent his career building databases, asked the obvious question, “What database did you use?” His son gave him the look kids reserve for parents asking questions that no longer make sense. “The AI just set one up.” PostgreSQL? MySQL? Something else? He had no idea. And he didn’t care. To him, the database wasn’t a decision to agonize over. It was a detail the agent handled while he worked on the actual idea.
That story stuck with us, because it’s not an outlier. It’s what’s happening with agentic AI everywhere. Customers tell Elizabeth, who leads marketing for AWS Databases, and her team, that their developers are shipping in days what used to take quarters. The people doing the building have changed too. Not just engineers, but analysts, and designers, who a year ago would have needed a development team to get started. Inside our own engineering organization, the shift is just as visible. Pravin sees engineers building agents that compress weeks of on-call work into hours. Product Managers are writing working backwards documents such as PRFAQs in a fraction of the time and showing up to design reviews with clickable prototypes instead of static mockups. Feature adoption dashboards are live within minutes of a launch. The distance between an idea and a working version keeps shrinking and so does the feedback loop around it.
This changes what developers need from the systems underneath them. When an agent can stand up a database in seconds, the database can’t be what slows the next idea down. It must get out of the way, whether the builder is a preteen inventor on a weekend project or a developer running a global application at an enterprise such as Netflix, BMW, and DraftKings. That’s the problem Aurora is designed to solve. From day one, Aurora has been shaped by three convictions, and agentic AI is making each one matter more for developer productivity: Meet developers, and the agents acting on their behalf, where they work. Absorb variability, so the application doesn’t have to. Grow with the application, from first prototype to global scale. In a world where ideas become applications in an afternoon, the companies that move fastest are the ones whose developers spend their time on the application, not the infrastructure underneath it.
In this post, we will use Amazon Aurora PostgreSQL-Compatible Edition to show how those three convictions look like in actual practice, and what they mean for developers and the agents working alongside them today.
Meet developers and agents where they work
The first conviction, meeting developers and their agents where they work, starts with the most basic question a developer asks, “Can I just start?” It is the easiest of the three questions to answer, and also the one the industry has historically gotten most wrong. For years, “just start” meant downloading something, configuring something, waiting for something. The bar is higher now, and it is going to keep rising as the developers growing up around AI-assisted coding tools become the developers shipping production software. Aurora PostgreSQL is designed to clear that bar.
Aurora PostgreSQL is available directly inside a growing number of AI coding tools, so spinning up a database doesn’t break the flow of building. A developer can ask their AI assistant in natural language to set up a Postgres database and get back a connected, queryable serverless Aurora database in seconds. The Aurora PostgreSQL MCP server is what makes this possible, giving agents and tools a direct path to the database across Kiro, Cline, Cursor, Claude, and other environments. Kiro Powers for Aurora PostgreSQL goes further, handling SQL execution, schema inspection, query monitoring, and Aurora best practices inside the same workflow. Developers using Vercel Marketplace and v0 by Vercel can create and connect to a serverless database through natural language flows that keep the application and the database in one place. The AWS Free Tier lets developers get hands-on with Aurora PostgreSQL at no cost while they prototype and learn.
Scale-to-zero pauses serverless databases automatically when they are idle and resumes them as soon as the first connection comes in, which means developers can spin up multiple environments and treat each one as a lightweight experiment rather than a long-lived commitment. That is a bigger shift than it sounds. When a database is disposable experimentation infrastructure rather than a permanent decision, developers spin up more environments, test more ideas, and let agents try things that used to require a meeting. The friction that used to suppress exploration is gone. It is the same pattern Pravin’s son stumbled into on a weekend project, now available to any developer who wants it.
Most developers are not starting from scratch. They are carrying forward years of tools, extensions, and patterns, and the last thing they want is for an agent-driven workflow to make them throw any of it away. Aurora PostgreSQL is fully PostgreSQL-compatible, so that investment carries forward. Developers keep using the migration tools they already rely on, including Liquibase Community, the ORM tools they build with, including SQLAlchemy, Prisma ORM, and Django ORM, and the extensions they depend on, including pgvector for retrieval-augmented generation (RAG) and similarity search. Aurora PostgreSQL also fits naturally with the agent frameworks that rely on PostgreSQL-backed persistence, memory, and checkpointing, including LangGraph, LangChain, and Letta. As agents accelerate the pace of development, the tools and patterns developers already know keep working.
Getting the database layer right matters whether the workload is two developers experimenting with agentic AI or hundreds of engineers running it in production. SurveySparrow operates five business units powered by agentic AI integrated throughout its product stack, with newly launched agentic AI capabilities for customer support and sales that depend on high-performance vector search combined with seamless transactional data access. Their development team migrated from a standalone vector database to Aurora PostgreSQL with pgvector, consolidating vector embeddings and relational data into a single database. SurveySparrow cut costs by nearly 50% and improved query latency by an estimated 30%. Their developers now spend more time focusing on building better AI rather than juggling multiple databases, and customers benefit from faster, more cost-efficient experiences.
Netflix shows what this looks like at scale. Netflix developers consolidated relational workloads from a self-managed PostgreSQL-compatible database onto Aurora PostgreSQL provisioned database instances, and they report up to 75% performance improvement, 28% cost savings across critical applications, and up to a 75% reduction in average latency for some applications. They no longer have to build and maintain their own database infrastructure and internal patching path to run PostgreSQL at that scale, which has given them back the time they were spending on database operations. As the workload became more demanding, they stayed on Aurora PostgreSQL and changed the operating model underneath it. That ability to evolve the database without leaving it is one part of the story. The other part is what happens when the workload itself becomes unpredictable, which is the next question Aurora answers.
Absorb workload variability
The second question, “will this thing hold up when the workload scales,” is the one that keeps engineering teams up at night. Variability used to come from one or two predictable places: a product launch, a holiday rush, spikes developers could see coming. That is not the world anymore. The same agents and faster release cycles reshaping our own Engineering and Product Management organizations are now hitting databases everywhere and without warning. The database has to absorb all of that variability as part of its normal operations, without turning instance sizing, failover behavior, and connection management into recurring work that pulls developers away from the application.
On Aurora PostgreSQL, serverless is the right default for most new applications. The reason is simple: developers shouldn’t have to predict a workload to run it. Aurora PostgreSQL serverless databases scale up as demand changes, and developers do not have to pick an instance size up front or revisit that decision every few months. When the database is idle, it scales down to zero automatically so idle environments don’t carry a cost. The moment activity returns, so does the database.
Scaling in Aurora serverless is measured in Aurora Capacity Units, or ACUs. An ACU is a bundle of compute and memory the database uses at any given moment. More load, more ACUs. Less load, fewer ACUs. Developers set a minimum and maximum range, and Aurora moves within that range in fine-grained increments as the workload changes. We have doubled the maximum scale of serverless to 256 ACUs – enough to take a preteen’s weekend project to a large production workload on the same database. Aurora serverless is now three generations (platform versions) in, each generation delivering roughly 30% higher throughput than the one before it, with the next already in development. Developers pick up every one of those gains simply by creating or upgrading a database. It’s one of the quieter reasons developers tell us they are choosing Aurora, and the same property they need when those workloads reach production scale.
A great example of that scale is BMW Messages. BMW Messages had to support high-throughput messaging workloads and historical data retention at the same time, a combination that would traditionally require ongoing developer attention to database growth and sizing. After adopting Aurora, BMW reports 99.99% uptime, 10 million messages per hour handled, an 80% increase in scalability, and a 40% reduction in costs. BMW also says Aurora serverless databases automatically handle compute scaling and reduce operational overhead. The productivity benefit at scale is that developers spend less time tending to the database and more on the application. It is the same benefit a two-person startup gets. Just measured in different units.
There is a quieter part of unpredictability that matters once an application is in production, which is how it behaves when something goes wrong. It is not enough for the database to scale. Applications also need to stay connected and recover cleanly when a writer fails over, when connections are disrupted, or when bursts of short-lived requests create connection pressure. Our view is that this should be the database’s job, not the developer’s. Aurora PostgreSQL addresses it through cluster-aware connectivity patterns rather than asking every developer to build that logic from scratch.
The AWS Advanced JDBC Wrapper supports Aurora PostgreSQL failover handling and awareness of writer changes within the cluster, along with IAM authentication and Secrets Manager integration. Developers stay focused on application logic rather than rebuilding connection resilience every time the workload or its scale changes. It is the kind of quiet work that usually does not show up in architecture diagrams but absolutely shows up in on-call rotations, and eliminating it is one of the most direct ways a database can give developers their time back. Variability is what developers deal with this quarter. The bigger question, and the one that decides whether they stay on Aurora, is whether it is still the right database a year from now.
Grow with the application
The third question, “will it still be the right database a year from now,” is the one that, for the three of us, feels the most personal. All of us have watched developers fall in love with a database early on, ship something real, earn real customers, and then be told eighteen months later that they had “outgrown” it and needed to migrate to something bigger. Pravin’s engineers have supported developers in the middle of that migration. My product team has sat through the postmortems. Elizabeth’s team has interviewed the developers on the other side of it, the ones describing what it cost them in lost velocity and team morale. That moment, when a developer is effectively punished for the database choice that helped them ship in the first place, is the moment we wanted to design out of Aurora entirely. It is also the reason one of our founding convictions for Aurora was that the database should grow with the application, from first prototype to global scale, on the same database.
AI-assisted development tools and agents make the cost of getting this wrong higher, not lower. Agents generate more code, more workflows, and more integration logic in less time, which means architectural churn is more expensive than it used to be. A database that is easy to start with but has to be replaced when the application needs higher throughput, safer upgrades, disaster recovery, or global reads does not save developers’ time. It defers the hardest work to the moment the application can least afford it, where it shows up as migration work, retesting, operational handoffs, and new failure modes, all hitting at exactly the point where the rest of development is accelerating. The database developers start with should still be the database they trust as the application becomes more complex, more global, and more operationally critical.
In practice, this looks like an arc with four stages. Early on, the developer wants one database that can flex between operating models. As the workload grows, they want to tune performance and cost in place rather than migrate. As the pace of change increases, they want upgrades to happen as part of normal delivery. When the application goes global, they want to extend across Regions without rewriting the application. Aurora PostgreSQL was built to keep developers productive through every stage of that arc, and we walk through each of them in turn.
Flex the operating model
Aurora PostgreSQL was built to flex from the start. Serverless databases and provisioned instances can coexist within the same Aurora cluster. Developers use serverless for variable workloads and provisioned instances for predictable, steady-state traffic, and move between the two as the application evolves without migrating data or changing how the application connects. Underneath, the self-healing, fault-tolerant, distributed storage layerAurora’s self-healing, fault-tolerant, distributed storage layer in Aurora makes the data durable across three Availability Zones (AZs) with continuous backups to Amazon S3, so durability and fault tolerance are built into the foundation rather than bolted on as the application grows. That architecture is backed by availability SLAs of 99.99% for multi-AZ deployments and 99.9% for single-AZ deployments. The question shifts from when a developer has outgrown the database to how they want to run the same PostgreSQL-compatible database as the workload changes around them.
Alloy shows what continuous iteration looks like on a stable database foundation. Its identity decisioning workflows evolve continuously as new integrations, fraud rules, and end-user requirements are introduced, which means schemas, query patterns, and workload characteristics shift alongside the application. With Aurora serverless databases, Alloy developers can continue iterating without turning each schema or logic change into a sizing decision, and have achieved up to 10x gains in overall transaction throughput as a result. That pattern, of the database quietly absorbing change rather than forcing developers to pause and negotiate with it, is the pattern we were hoping to see in production.
Tune the database in place
Once the operating model can flex, the next thing developers want is to tune the database without moving to a different one. As applications scale further, Aurora gives developers multiple ways to optimize performance and cost within the same cluster. Aurora I/O-Optimized improves performance and reduces costs for I/O-intensive workloads. Clari switched to Aurora I/O-Optimized to address rising I/O costs at scale and reduced costs by 50%. MoneyLion used Aurora I/O-Optimized together with optimized reserved capacity purchasing to achieve 55% cost savings. Aurora Optimized Reads addresses a different performance profile, adding a local NVMe cache tier on the provisioned database instance so frequently accessed data can be served from fast local storage rather than shared distributed storage. Claroty used Aurora Optimized Reads to improve database performance as its environment scaled. Mindbody applied it to read-intensive workloads and improved both query latency and costs. Graviton-based configurations extend that further with additional throughput and price-performance gains. As agents generate more code paths, more services, and more read and write activity, the ability to tune both performance and cost within the same cluster keeps infrastructure from becoming a bottleneck on the pace of development.
Keep the database current
Tuning a database in place only works if developers can also keep it current. Safe change management is another place where the pressure to re-architect shows up indirectly, and it is one of the most common reasons developers tell us they feel stuck on an older database version. For smaller groups of developers, the concern is time. Upgrades feel risky because there is no one to manage the fallout if something goes wrong. For larger organizations, the concern is coordination. Upgrades require change control processes, maintenance windows, and cross-team alignment that push database lifecycle work to the back of the queue. In both cases, developers start treating upgrades as migration projects rather than part of normal delivery, which turns a routine operational task into a quarterly event. That gets more expensive as agents increase the pace of application change, because version lag compounds quickly against everything moving around it.
Aurora PostgreSQL gives developers two upgrade paths while keeping them on the same database engine. In-place minor version upgrades are the simplest path, and for Aurora PostgreSQL minor versions released after 14.20, 15.15, 16.11, and 17.7 upgrades typically complete with downtime of under a few seconds. AWS Organizations upgrade rollout policies extend that further by letting developers centrally manage and stagger automatic minor version upgrades across accounts and databases, so changes can be validated in development and test before being applied to production. For developers who want more control, Blue/Green Deployments keep a synchronized environment alongside production so upgrades and other changes can be validated before switchover with minimal interruption. Wiz upgraded Aurora PostgreSQL from version 14 to 16 with near-zero downtime using Blue/Green Deployments, reducing downtime per cluster from roughly an hour to around 30 seconds. When agents are driving more frequent releases and schema changes, upgrades that happen as part of normal delivery rather than in spite of it keep the development cycle moving instead of pausing it.
Go global without starting over
The final stage of the arc is the one where developers have historically been asked to start over. Once an application needs to run in more than one Region, the default playbook has been a new data layer, new connection logic, and new routing rules in the application itself. On Aurora, that tax doesn’t exist.
Aurora Global Database extends Aurora PostgreSQL across multiple AWS Regions, providing cross-Region disaster recovery and low-latency local reads, with support for up to 10 read-only secondary Regions. For developers, global writer endpoints unlock a new level of productivity. A single endpoint automatically routes write traffic to the current primary Region, so after a cross-Region failover or switchover, applications connect to the new primary Region without developers updating connection strings or building Region-aware routing logic into the application. That removes an entire category of code developers used to have to write, test, and maintain, and it removes an entire category of incident where the database has recovered but the application has not caught up yet.
Write forwarding goes further by letting applications connected to secondary Regions issue writes that are automatically forwarded to the primary Region, so developers can run active applications in multiple Regions without splitting write logic across separate data paths. Global reach becomes part of the same Aurora PostgreSQL cluster rather than a reason to introduce a parallel data store or redesign how the application handles writes.
S&P Dow Jones Indices built new thematic indices using Global Database and write forwarding so applications in multiple Regions could remain active for appropriate operations without redesigning the data layer around a separate global architecture. Newgen Software adopted Global Database to achieve cross-Region failovers with a recovery point objective of under one second for planned failovers and under one minute for unplanned failovers. PayU used Global Database to enable replication across Regions without affecting database performance, support low-latency local reads in each Region, and improve disaster recovery for Region-wide outages. In each case, developers went global without starting over.
DraftKings is the arc in a single customer. What began as a startup building a daily fantasy sports product has grown into a business serving millions of customers on one of the most demanding real-time workloads on the internet, with traffic that spikes violently around live sporting events. Through all that growth, DraftKings has stayed on Aurora, evolving the operating model, performance profile, and global footprint underneath the same database rather than migrating off of it. The database that was right for a small team shipping a new idea is the same database running the company today. That is the story we want every developer starting on Aurora to be able to tell.
It is the same story at every scale. The weekend project Pravin’s son built and the global application PayU’s developers run are on the same Aurora PostgreSQL, with the operating model, performance profile, and geographic footprint tuned to where the application is in its life. Behind all of it is a decade of running some of the most critical workloads on the internet, the lessons learned from millions of clusters and every edge case in between. There is no compression algorithm for experience, and that experience is in every decision Aurora makes on a developer’s behalf. That is what we mean when we say the database should grow with the application. As workloads stabilize and usage becomes more predictable, developers have one more lever to pull. Database Savings Plans provide a commitment-based pricing model across AWS database services, including Aurora’s provisioned database instances and serverless usage, with savings of up to 35% over on-demand rates. Cost optimization becomes part of how developers evolve the database over time, not a trigger for another database decision, and not a reason to start the cycle over.
Ready for what comes next
The craft of building software is being rewritten in real time. Pravin’s son didn’t know what database he used that weekend, and he was right not to care. That is the bar. The database should disappear into the work, whether the builder is a preteen with an idea on a Saturday afternoon or a team running a global, internet-scale application. Aurora PostgreSQL was built to clear that bar at every stage in between—starting fast, absorbing the unpredictable, and growing with the application without ever asking the developer to start over.
We are a long way from done. Aurora is getting faster generation over generation. The integrations with AI-assisted development environments are getting deeper. The operating models inside a single cluster are getting more flexible. The arc from first prototype to global scale is getting shorter. Our job is to keep compressing that arc until the database is the last thing a developer thinks about and the first thing an agent reaches for.
If you are a developer reading this, the best time to start is now. If you are an agent reading this on a developer’s behalf, you already know what to do.