Aurora DSQL turns agent sessions into a repeatable growth workflow

How Aurora DSQL gives disposable coding sessions durable evidence, shared operational state, and an AWS identity path—while keeping static-site changes reviewable in Git.

A new coding session should be able to answer “what changed?” without downloading the same reports, rebuilding yesterday's spreadsheet, or asking someone to paste the last conversation.

At OCDevel, Aurora DSQL gives that session somewhere to look. Search performance, affiliate data, product records, and recurring maintenance outcomes survive the terminal that collected them. A session on another machine can query the same records and continue from the evidence already gathered.

The useful part is the workflow around the database: collect information once, retain its provenance, query it from whichever tool is doing the work, and publish changes through a visible review step.

Memory you can query

“Agent memory” often means storing conversations or retrieving fragments of old notes. Our database holds the project's durable facts: a source observation, the last completed maintenance run, a product's current record, an editorial opportunity, or a decision waiting for a human.

Conversations, plans, and the running agent's lifecycle stay in the coding tool. A new session needs to know which report was successfully imported and when its data was observed. It rarely needs every message exchanged while importing it.

That distinction makes the stored information useful beyond any one assistant. A script, an analyst, and a coding agent can read the same table. SQL lets each ask a different question without needing a custom memory integration.

Temporary JSON files and grep are useful during an investigation. They become awkward when the question needs a date filter, a join across products and links, or an aggregate over several observations. A database lets the session ask for that result directly, with a schema that explains what the fields mean.

SQLite is an excellent local version of this approach. The complication arrives when several machines and sessions need to update the same dataset: distributing and merging a changing database file becomes its own coordination problem. A remote relational store removes that data-file handoff and the temptation to commit a mutable SQLite binary to Git. Concurrent writes still need transaction design, and published content still deserves a readable diff.

It also makes missing information visible. Our affiliate importer records the scope covered by a successful import. A product outside that scope has an unknown campaign status. An empty query result alone cannot establish that no campaign exists. Keeping this distinction in the data layer prevents every new session from learning the same lesson again.

Turn separate reports into a working dataset

A website's useful evidence arrives through several doors:

• Google Search Console supplies search clicks, impressions, pages, and queries.
• Website analytics supplies visits and outbound-link activity.
• Affiliate exports supply measured earnings and campaign information.
• DataForSEO supplies additional keyword, ranking, and merchant evidence.
• The product catalog connects those observations to the pages and products we can actually improve.

The storage follows the workload. Raw website analytics stays in S3 Tables and is queried through Athena. DSQL holds operational records, structured history, and the static site's source tables. Larger supporting archives can live in S3. Scripts assemble the relevant results; DSQL does not magically query every external service.

This is where the workflow becomes especially useful: the same evidence can answer a growth question, explain a regression, and identify the next worthwhile edit. You can move from “traffic seems down” to a specific page, query group, product, and action.

Find the page worth improving next

Search Console tells us where the site already appears. A page with meaningful impressions and weak click-through deserves a different investigation from a page that never appears at all. Its query history helps establish the search intent: perhaps the title promises the wrong thing, a comparison lacks an important option, or the page needs to answer a question readers actually ask.

DataForSEO adds a different perspective. Search Console describes our existing visibility; external keyword and ranking data helps investigate demand where we have little or no presence. DSQL now retains those responses alongside queryable search results, keyword volumes, monthly demand history, rankings, and merchant observations. Collection dates and request scope travel with the evidence, so later sessions can compare compatible observations instead of reconstructing an investigation from scattered reports. Existing S3 archives remain recovery copies; new DataForSEO history and caches live in DSQL.

Competitor discovery makes this practical: collect queries where comparable pages appear and ours do not, retain the results, then qualify relevant leads against the product catalog before opening research work. A separate fixed panel records the sources returned in sampled ChatGPT answers. Together, these extend the questions we can investigate beyond our current search traffic. They measure the requested searches and sampled answers, with their coverage limits; they do not represent the whole market.

An opportunity can carry the target page, evidence, proposed change, and status. The next session gets a concrete lead it can verify. It can also see that someone already resolved or rejected it.

Separate losing visibility from losing clicks

Daily history makes a traffic decline investigable. Compare clicks and impressions over matching windows: falling impressions suggest a visibility or demand question; stable impressions with fewer clicks suggest a click-through question. Neither pattern establishes the cause, but each narrows the next investigation.

Here is an illustrative query using our actual Search Console daily schema. It sums page observations for the last 28 calendar days, excluding today. The property URL is a placeholder for whichever property the investigation concerns:

SELECT page,
       COUNT(DISTINCT date) AS observed_days,
       SUM(clicks) AS clicks,
       SUM(impressions) AS impressions,
       SUM(clicks)::double precision
         / NULLIF(SUM(impressions), 0) AS ctr
FROM gsc_daily
WHERE property = 'https://example.com/'
  AND page <> ''
  AND date::date >= CURRENT_DATE - 28
  AND date::date < CURRENT_DATE
GROUP BY page
ORDER BY clicks DESC;

The observation count is there for a reason: recent source data may be incomplete. Compare against the preceding window only after checking coverage. A missing day is not automatically a zero, and Search Console query exports can omit data. Keeping dates and provenance beside the metrics helps the analysis acknowledge those limits.

Follow a reader from interest to a buying path

Search clicks tell us how readers reach a page. Outbound-link activity tells us which products interest them. Affiliate reports can supply measured orders and earnings. Those are different signals, and combining them helps prevent a popular page from monopolizing the work queue while a valuable product link quietly breaks.

For example, a product with meaningful outbound interest but no affiliate buying path creates a specific task: investigate a suitable program or correct the destination. A product with measured orders and an old price check creates another: verify that its listing and recommendation are still accurate. A high-traffic comparison with little outbound interest calls for a different investigation again, perhaps into whether it helps readers make a decision.

This is also where measurement needs to outrank a model. Our workflow distinguishes a measured zero orders from missing order data. It should not replace an observed zero with an optimistic conversion estimate. Likewise, an unsuccessful or out-of-scope campaign import cannot justify declaring that no campaign exists.

Build a repeatable optimization loop

Once observations have dates and work has a durable status, the next run can return to the same question. Refresh the evidence, examine whether the relevant metrics moved, and decide whether another change is justified. Historical snapshots make that possible after the original terminal and its temporary files disappear.

Before-and-after movement does not prove an edit caused the result. Seasonality, rankings, and source coverage can change too. What the database provides is the material needed to investigate: the windows being compared, the source observations, and the records identifying the work. It becomes practical to revisit a hypothesis instead of letting the last confident summary stand forever.

Source history matters as much as the latest answer. Our Search Console archive keeps original snapshot bytes alongside their property, observation time, date window, and checksum, then derives queryable daily and query history. If a projection fails, it can be rebuilt from the retained source. If an analysis looks suspicious, we can inspect the evidence behind it.

That is particularly valuable with paid or rate-limited APIs. Our discovery and AI collectors retain their collection plan and captured responses in DSQL. A later session can rebuild analytical rows from those bytes and resume remaining work without buying the captured observations again. If a request’s outcome is uncertain and no response was retained, the collector stops automatic retries. Reusing a completed result also requires compatible request scope and adequate freshness; a different market, device, or investigation may need a new observation.

Why DSQL fits an AWS workflow

A shared Postgres service could deliver much of this. DSQL fits here because AWS already provides the storage, execution, diagnostics, and identity system.

You can adopt this gradually. A local prototype can begin with AWS access keys supplied through an untracked environment file. Later, the same AWS credential chain can use an SSO profile for interactive work or an attached IAM role on a cloud host. The database stays put while the way you grant access improves.

Human CLI access uses IAM Identity Center. After configuring a named profile, the ordinary login is:

aws sso login --profile dev

Existing scripts can keep selecting that profile while the CLI obtains temporary credentials through the session. Moving away from permanent human access keys does not require inventing a new authentication scheme for every script. AWS documents the profile and refresh behavior in its SSO configuration guide.

DSQL uses that AWS identity path to authorize database connections. There is no separate permanent database password to distribute. Access inside the database still requires deliberate database roles and grants: IAM connection permission is only one part of the authorization model. See DSQL authentication and authorization.

The same approach supports incremental access. A job can receive access to a particular S3 prefix when it needs source files, or CloudWatch read permissions when it needs production diagnostics. Each additional capability is a policy decision with a concrete purpose.

Human login and unattended execution need separate credential designs. SSO works well for an interactive session; background jobs need an appropriate workload identity for their host. A database gateway also needs intentionally scoped SQL access. None of those permissions become least-privilege automatically because the system uses IAM.

Also, a login expiring does not instantly disconnect every established SQL session. DSQL authorizes connections separately, and existing connections can remain authorized after IAM access is revoked. Session-based access is useful without pretending it has stronger revocation behavior than the service promises.

Reach the same data from a fresh environment

A cloud coding host may disappear after a task. Its local files make a poor home for the only copy of an imported report.

A remote database makes that host replaceable. Once the next environment has the repository, its dependencies, an authorized identity, and network access, it can use the same query tools. The continuity belongs to the dataset.

We needed one transport adaptation. Some coding sandboxes cannot open a PostgreSQL connection on port 5432. Our scripts invoke a small Lambda over HTTPS; the function opens the database connection inside AWS and returns the result. The function generates its own DSQL authentication token.

That gateway is our code, with its own permissions, latency, and maintenance cost. DSQL speaks the PostgreSQL wire protocol; the HTTPS route is an adapter we added for this environment.

The data also benefits from a workload that comes in bursts. DSQL bills database activity and storage, with no DPU activity charges while idle. Storage and supporting services still cost money. This suits periodic ingestion and investigation, although actual cost depends on query shape and volume. AWS's pricing page explains the billing model.

Keep the website static and the changes visible

Moving source tables into a database need not make every page depend on a live database query.

Our static content tables live in DSQL. We export them into generated TSV files, review the diff, and let the build generate the site's data modules. Long-form content can continue living in Git.

The path is straightforward:

Source reports → ingestion → DSQL → generated TSV diff → build → static pages

The database provides a shared editing surface. The exported files show exactly what changed. The build gives the public site a stable artifact that can be served without contacting DSQL for those tables.

This is an especially useful combination for assisted content maintenance. A session can update a product record through the same typed tooling used by an importer, then produce a small, readable diff. The reviewer can inspect the changed values instead of trusting a message saying “the database was updated.”

Shared state still needs careful writes

Multiple sessions can read the same database without copying files between worktrees. Concurrent writes need more thought.

DSQL uses optimistic concurrency control with snapshot isolation. Conflicting transactions can fail and require a retry; the database does not turn a larger business operation into an exactly-once workflow. Our client bounds its conflict retries. Work that combines a fresh read, a shared mutation, and a publication dump also uses a cooperative local lock. That lock covers linked worktrees on one host, not every machine that can reach the cluster. AWS describes DSQL's concurrency model here.

There are practical database limits too. A transaction can modify up to 3,000 rows and 10 MiB of data, and last up to five minutes. Imports must batch their writes. SQL compatibility has edges: referential integrity needs application validation, and indexes use asynchronous creation syntax. We keep the main product database separate because its requirements differ from this operations store. See DSQL quotas and PostgreSQL migration guidance.

Prefer learning through a story? Cyberpunk AI explores AI and agentic systems through fiction. Gnothi can also create a nonfiction series around what you want to learn.

When Neon or PlanetScale makes more sense

The main benefits here come from shared relational storage and a disciplined ingestion workflow. They are not exclusive to DSQL.

Neon is appealing when disposable database branches are central to development. Its branching workflow gives isolated environments, and its serverless driver carries queries over HTTP or WebSockets. That built-in transport could remove the custom gateway our sandbox requires.

PlanetScale also offers PostgreSQL. Its database branches provide isolated deployments for development and testing, including creating a branch from a backup. Compare the actual PostgreSQL offering and workflow; treating PlanetScale as only a MySQL service misses an option.

For our shared operations dataset, the attraction is AWS identity and the surrounding AWS tools. A new session can inspect source files, query retained evidence, and investigate logs through an access model the rest of the system already uses. It can leave behind a corrected record, a dated observation, and a reviewable publication change that the next session can use immediately.