Aurora DSQL is a managed SQL database from AWS. It's a good place to keep data that a coding agent will need again: imported reports, research results, product records, and decisions waiting for you. The data survives when you close the terminal, start a new conversation, or switch machines.
Any shared database can do that. DSQL is particularly useful if you're already using AWS: agents can connect through AWS credentials, you don't have a database server to maintain, and idle periods don't incur database activity charges.
Suppose you ask an agent to figure out which pages on your website need updating. It downloads search reports, checks a few products, and gives you recommendations. Next week, you want it to check again.
If the results only exist in the conversation or a temporary folder, the next session has to recover them or repeat the work. With a database, it can read last week's observations, collect what's changed, and compare the two. A scheduled script can use those same records while you're away.
Useful records are fairly ordinary: a page URL, the date you checked it, the source of a number, the number itself, and whether you've acted on it. Keeping dates and sources matters. An agent needs to distinguish an old price from a current one, or a missing report from a report showing zero sales.
SQL makes those records easy to use together. An agent can find products that haven't been checked in a month, compare traffic across two periods, or join a list of broken links to the pages containing them. You can inspect the same tables yourself. You don't need a particular assistant's memory feature to get your data back.
Saved API responses can also avoid paying for the same research twice. Keep the request details and collection date with the result so the next session can decide whether it's still useful. Large files can go in S3, with their location recorded in the database.
SQLite is an easy starting point. It's a file, it needs no database service, and an agent can query it with SQL. If your sessions all use the same persistent file on one machine, it already gives you durable storage. Starting a new conversation doesn't require a new database.
The trouble starts when each environment has its own copy. An agent on your laptop updates a product record. Another in a cloud sandbox imports yesterday's report. Now there are two databases, each containing something you want to keep.
Committing the SQLite file to Git doesn't solve that. Git can't merge changes inside the database the way it merges text. Choosing one branch's file can discard records added on the other. Exporting SQL or JSON makes changes readable, but you still have to reconcile competing updates to the same record.
Git worktrees make this easy to stumble into. They're useful for letting agents work on separate code changes, but a tracked database file gives each worktree its own version of the data. Pointing every local session at one SQLite file avoids the copies on that machine. It doesn't give a remote coding environment access to that file.
A shared database such as DSQL gives those environments one dataset. Your laptop can read the report the cloud job imported. A new session can check which records were updated without locating the previous session's files. Code branches can come and go while the operational history stays in place.
That also means a Git branch doesn't isolate database writes. Test changes need separate data, and competing updates still need transactions and conflict handling. The benefit is that you resolve changes against shared records instead of trying to merge whole database files.
AWS identity is the main reason I'd choose DSQL for this setup. If an agent already has permission to read files in S3 or inspect logs in CloudWatch, database access fits into the same permissions system.
DSQL uses short-lived authentication tokens generated from AWS credentials. You don't need to distribute a permanent database password to each coding environment. For interactive work, you can use an AWS SSO profile; a job running in AWS can use an attached IAM role. You still need to configure database roles and SQL grants to control what each connection can do. AWS's authentication guide explains both layers.
That lets you give a reporting job read access and an importer permission to update its tables. A fresh coding environment needs the repository's query tools, an authorized identity, and network access. The stored data is already there.
The billing model also fits occasional agent work. A session might import a report and run several queries, then leave the database alone for hours. DSQL charges for activity and storage, with no activity charges while idle. Storage still costs money, and large scans can make an active session expensive. AWS lists the pricing and free allowance here.
AWS handles the database infrastructure and replicates the data across three availability zones in a region. You don't choose an instance size or maintain a database host just to keep a small shared dataset available.
Neon gives you the same shared-storage benefits and can scale compute to zero. I'd favor DSQL if S3, Lambda, and IAM are already part of the setup. Database access then uses the AWS credentials and permissions you're already managing.
Neon's database branches are useful for testing against isolated data. Its serverless driver supports HTTP and WebSockets, which helps in sandboxes that block ordinary PostgreSQL connections. DSQL uses the PostgreSQL wire protocol; an HTTPS gateway would be something you'd need to supply and maintain.
DSQL is PostgreSQL-compatible, so familiar SQL and clients are useful, but you should check the features your application depends on before moving an existing database. Its PostgreSQL documentation covers compatibility and transaction behavior. Concurrent changes can cause a transaction to fail and need a retry. Imports need to respect transaction limits, and retrying database work doesn't make an external action, such as buying an API report, safe to repeat.
For a new agent storage setup, start with one recurring task. Save its inputs, results, dates, and sources, then have the next session query them. You'll have something concrete to build on: last week's work is available without having to explain it all again. A nightly Claude Code run with a shared work queue shows a fuller setup built on tables like these.