2025 was the year we started noticing things we couldn’t easily explain away.

We shipped a lot, but what stuck with us were the patterns we kept seeing in production. Traffic didn’t line up with application releases. Queries that looked reasonable in isolation would end up destabilizing databases once deployed. In many cases, it looked like the usual tension between application teams moving quickly and database or platform teams trying to keep systems stable.

Application teams weren’t just shipping more frequently; they were introducing new queries and access patterns without the usual design cycles. Traffic would spike in places no one had explicitly planned for. Systems that behaved predictably under test would fail in production in ways that were hard to reason about after the fact.

As we dug into these cases, one factor kept showing up: more teams were starting to rely on LLM-powered tools to generate and evolve application logic. Queries were no longer carefully crafted artifacts; they were being generated, revised, and deployed continuously. The result was database workloads that shifted faster than most infrastructure was designed to adapt to.

By the end of the year, it felt clear that this wasn’t a temporary mismatch or a tooling hiccup. It was a change in how software gets written, and it meant database performance could no longer be managed primarily through manual tuning and static assumptions.

Community and Events

We started the year at FOSDEM, and spent the rest of 2025 trying to stay close to where these changes were already happening.

Our team sponsored, attended, hosted, or spoke at PGConf Germany, PGDay Blumenau, PGDay Brasília, PGDay Austria, MySQL Summit Online, PGConf India, AWS Summits in NYC and São Paulo, the MySQL HeatWave Summit, and MySQL Brazil Conf.

What stood out wasn’t just how many events we went to – it was how similar the conversations were, no matter where we were. Teams across the PostgreSQL and MySQL communities were asking the same questions: how do you scale read-heavy systems without blowing up costs? How do you deal with access patterns you didn’t design for? How do you keep performance stable when AI-driven features start hitting existing databases?

In our webinars, live demos, and deep-dive sessions, we tried to focus less on theoretical limits and more on what actually breaks under real load. Those conversations shaped far more of our thinking than any roadmap document ever could.

The Launch of QueryPilot

The clearest outcome of what we learned in 2025 was the launch of Readyset QueryPilot.

QueryPilot is a zero-touch, automatic caching layer for MySQL OLTP workloads, with PostgreSQL support underway. It watches live traffic, identifies expensive queries, and optimizes them automatically without asking developers to rewrite code or guess what might break next.

From WordPress benchmarks to Black Friday–scale traffic, teams saw immediate improvements in throughput and latency. But what mattered more to us was why it worked.

Modern workloads, especially those shaped by AI and automation, don’t lend themselves well to pre-planned optimization. Query patterns change too quickly, and the cost of being wrong is too high. QueryPilot was built around that reality. Instead of asking humans to anticipate performance problems, it treats optimization as something that has to happen continuously, driven by real traffic.

By the end of the year, this reinforced something we kept hearing everywhere: teams don’t just want faster databases. They want infrastructure that can keep up on its own.

Product Improvements

Alongside QueryPilot, we spent 2025 strengthening the foundations of Readyset.

We expanded SQL compatibility with support for window functions, arrays, straddled joins, and time-series helpers. We made schema changes safer, invested in smarter snapshotting, and improved observability and debugging across the system.

We also expanded query coverage through a new query rewrite layer, a faster query parser by adopting and contributing to sqlparser.rs, and a cost-based optimizer in our query planner, while laying the groundwork for internal shallow caching.

Readyset Cloud added several new features like QueryPilot, Observability clusters, BYOVPC, faster deployments, among others.

None of these changes were flashy on their own. Each took months to develop and roll out, but all of it was critical and focused on making Readyset’s IVM engine more capable and helping customers deploy more and more queries in production.

Benchmarks, Blogs, and Shared Learnings

We also spent a lot of time writing in 2025.

We published technical blogs, benchmarks, and explainers on everything from pagination and window functions to collation, dataflow, and database performance under AI-generated workloads.

The motivation was simple. Database systems don’t fail randomly. When something goes wrong, there’s usually a reason, even if it’s buried a few layers deep. We wanted to help teams understand those failure modes earlier, before they turned into late-night incidents. You can check out everything we published here - readyset.io/blog

Partnerships

As the challenges we were seeing became more global, it became clear that we couldn’t address them alone.

In 2025, we announced our first partnerships focused on making database scaling easier to adopt in production. With PerformanceDB, we’re helping teams in Brazil scale MySQL through localized support, monitoring, and faster deployments. With CYBERTEC, we’re working with long-time PostgreSQL experts to support teams scaling Postgres with Readyset. We were named “Technology Partner of the Year”. 

We also formed partnerships across Europe, India, and the Middle East, which we’ll be announcing in the coming year.

Looking Ahead

To our customers, beta users, and the PostgreSQL and MySQL communities: thank you. Your feedback, production data, and hard questions shaped our direction far more than anything we could have planned in isolation.

As we head into 2026, we’re excited to support more teams as they scale databases without duct tape, manual invalidation, or sleepless nights. We’ll start the year with our third appearance at FOSDEM and look forward to continuing these conversations in person.

Our Prediction for 2026

If 2025 was the year the cracks became visible, 2026 will be the year they become impossible to ignore.

Enterprises will continue pushing AI deeper into production systems, particularly in on-prem and hybrid environments. The database scaling techniques most teams rely on today, predictable workloads, static capacity planning, and manual tuning, were built for a world where humans wrote most queries and applications evolved slowly.

That world is fading.

Agentic systems will move from experimentation into production. Enterprises will deploy large numbers of autonomous agents that continuously read from operational databases, ask exploratory questions, and generate speculative access patterns that bear little resemblance to traditional application traffic. These systems will expect immediate answers, even as their behavior shifts minute to minute.

In response, familiar approaches will start to strain. Manually maintained caches will slow teams down. Read replicas will become economically difficult to justify. Distributed databases will help with throughput, but not with latency or access control at agent scale.

What comes next is a new baseline. Database infrastructure will need to observe live traffic, enforce access policies, and optimize performance automatically. Scaling will move from something teams engineer by hand to something infrastructure handles continuously.

As we close out 2025, one thing feels clear to us: the way databases are accessed is changing faster than the way they are scaled. The next wave of software will be built by systems that move at machine speed, not human pace, and database infrastructure will have to evolve to match.