AI Agents Created 80% of New Databases

Databricks reports that on Neon, its serverless Postgres platform, AI agents now create 80% of all new databases, up from almost none two years earlier. Most of those databases are short-lived, spun up by an agent to test something, run a task, or back a feature it's building, and often without a human in the loop.

When an agent creates a database, it can also make the decisions that come with it. It picks the schema, chooses the column types, decides which columns get indexed, if any, and sets up the relationships between tables. These are the same decisions a person would work through carefully, except the agent makes them in seconds, based on whatever context it had at the time.

This can leave your team inheriting three gaps:

• The reasoning isn't recorded anywhere. A schema or migration shows what an agent created, but not why it denormalized a table or picked an unusual primary key. So when you're later debugging why the schema is a certain way, there may be no answer to find.
• The design reflects the given context, not the workload. An agent builds a schema around the immediate task in front of it, not around how the data will be queried a few months later. Choices that were reasonable for a prototype can easily become something you're fighting once real traffic arrives.
• Ownership can arrive too late. A database that starts as an agent's scratch space can drift into production before anyone reviews its schema, sets performance expectations, or takes ownership of it. It becomes load-bearing without a clear handoff.

None of this is an argument against letting agents provision databases. It's useful, and spinning one up in seconds instead of waiting on a provisioning ticket. The issue is scale: agents can create and change databases faster and in greater numbers than a manual review process can handle. What to watch is the graduation point: the moment an agent-created database stops being temporary and starts serving a workload your team or customer depends on.

The same review problem continues after provisioning: when agents generate production queries, teams cannot manually inspect every statement. The practical response is automated governance at both stages. At provisioning, assign an owner and expiration date, then block production access until the schema and operational review is complete. At runtime, identify which agent issued each query, limit what it can access and spend, and stop unsafe or unexpectedly expensive statements before they reach the database.

🔍 What We're Watching in the Database Ecosystem

Anthropic Revenue Surges to Over $11.5 Billion in Second Quarter

Anthropic told prospective investors its second-quarter revenue passed $11.5 billion, up from $787 million a year earlier and $4.73 billion in the first quarter, with positive adjusted operating income. The figures are preliminary and come as the company moves toward a possible fall listing.

Sixteen Locks Ought to Be Enough for Anybody

Every Postgres query takes a lock on every index on the table, including the ones the planner looks at and discards, so a table with a primary key and twenty secondary indexes costs 22 relation locks per execution. Christophe Pettus walks through why that spills off the 16-slot fast path and into shared lock manager contention, and what changed in Postgres 18.

What Flyway validate actually checks

flyway validate compares migration file checksums against the history table and never inspects the schema itself, so a manual ALTER TABLE in production leaves it passing green. Drift detection does exist in both Flyway and Liquibase, though the useful pieces sit behind paid tiers or hosted platforms, which is a large part of why most teams first run it during the retrospective.

In Case You Missed It

The Subquery Positions Readyset Used to Reject: A follow-up to our earlier SQL-rewrite deep dive. This one walks through four query shapes the dataflow engine used to turn away, subqueries in HAVING, ORDER BY, and inside join conditions, and how each one gets rewritten into a form the engine can cache and maintain incrementally. The LEFT OUTER JOIN case is the interesting one, since the obvious rewrite quietly returns wrong answers, and the post shows why.

We're getting more social, catch the latest on Bluesky, X, dev.to, and Medium too.

Know a database aficionado who'd appreciate this? Forward it their way.