The 2025 Data Recap

This is a snapshot of the data world as it looked on the last day of 2025, written as a year in review rather than as current advice. Five things defined the year for the teams I worked with. AI became genuinely useful for coding, debugging and repetitive development work, while still producing suggestions that were workable rather than correct. Teams increasingly wanted analytics data pushed back into their operational tools, and the near real time expectation that came with it strained small pipelines. dbt and Fivetran merged, with no visible change to existing dbt projects by year end. And despite unlimited information and instant answers, design and strategy remained the thing teams could not outsource, which is part of why my own work shifted toward one and two person data teams.

AI in 2025

The topic of the year, without question. It dominated social media, the news and most conversations I had with teams.

My honest read at the close of 2025 was that we were still at the beginning and still figuring it out. These are the notes I took from clients and teams actually using it.

Where it genuinely helped

• Coding and debugging. Help writing a query, changing some logic, or finding an error faster than you would alone.
• Tedious development. Applying a naming convention across many files, or generating repetitive blocks once the pattern is clear.
• In tool assistants. Databases and platforms shipping a question box that writes or suggests the syntax for you.
• Pull request checks. Tooling on GitHub or GitLab reading the context of a change, generating documentation and running a broad set of tests automatically.

Most of the coding help was being used the way people use a search engine, except inside the editor while you type. That alone made teams more productive on the tactical work.

The pull request example was the most impressive one I saw. It was doing more than I was familiar with at the time, and the team running it was comfortable with that.

Where it fell short

The output worked without being right. When I looked at what was being suggested, it frequently was not the optimal approach for the situation, just an answer that ran.

The risk there is teams relying on the output blindly. You end up with a house of cards: logic and systems that function technically while nobody quite understands why, so every break turns into more patchwork.

That is why understanding the work still mattered. You need enough judgment to tell whether what came back makes sense for what you are actually trying to do.

The over-prompting trap

The other pattern, and I was as guilty of it as anyone, was spending more time coaxing a tool toward the right answer than solving the problem would have taken.

It is inefficient and a bit of a handicap. Steering a conversation is not the same as thinking something through.

On balance, AI at the end of 2025 was a strong accelerator from zero to one and a good way to boilerplate your way into a project. Human instinct, strategy and nuance were still doing the load bearing work.

Operational versus analytical use cases

The second trend was about how teams wanted to use their data, and I tend to split these conversations into analytical and operational.

Analytical is the familiar path. Pull from sources, move the data through a pipeline, land it in a report, and look back at what happened. It is usually batch, whether hourly or daily.

Operational is the return trip. You take the field you just built in the warehouse and push it back into the CRM or business application where people work. The industry term for this is reverse ETL.

Why teams wanted it

It makes sense. If you combined several sources to produce a clean customer field, you want that same value showing up consistently in every tool the business touches.

The concept is not new. What changed was how many small teams were asking for it.

Where the design got hard

The trouble was timing, not plumbing. Once that field exists in an application, nobody wants it refreshed once a day. They want it every ten or fifteen minutes.

That is reasonable to ask and expensive to build. The field depends on logic across multiple sources, so making one column near real time tends to drag the whole pipeline toward real time with it.

The teams asking for this were usually one, two or three people. That architecture needs more complexity, more integrations and more ongoing management than a team that size can carry.

The option I usually suggested

Wait a little longer. Refresh the data and push it back at the end of your normal pipeline, even if that means an hour or a few hours of delay.

You keep the engineering simple, you can use an off the shelf reverse ETL tool, and you still get the result. It is less immediate than people want, and for most teams that was the right trade in 2025.

The dbt and Fivetran merger

The big tooling news of the year was dbt and Fivetran merging. It was not especially surprising. There had been years of speculation that dbt would be acquired or combine with someone.

My hope as a user was that both would keep operating as independent tools under one roof, rather than becoming a bundle you have to adopt together.

As of the last day of 2025 I had not seen any material change. dbt projects behaved the same, teams were starting new ones the same way, and nothing in the day to day had shifted.

The thing I most wanted to see preserved was the open source side of dbt staying available for teams that only want that piece. Whether that held is a question for the following year.

Design and strategy stayed the gap

This was the area teams still asked for the most help with, and it is worth sitting with why.

There is no shortage of information. Documentation, courses, social posts, and an AI that will answer any question in a second.

Information was never the constraint. Teams still have to process all of it, make decisions, and then stay consistent with the decisions they made.

Project design

Naming conventions and project structure. AI can accelerate the setup, but somebody has to own the standard and keep the team on it. When nobody does, I walk into projects that have clearly drifted.

Query design

You would think inconsistent SQL would be solved by a tool that can read your whole project. It can genuinely review and recommend.

What it struggles with is context and nuance. That is why teams still wanted an extra set of eyes to connect their strategy and vision all the way down to the implementation.

Leaning into one person data teams

The last note is personal. Over 2025 I shifted most of my focus to one person data teams and small groups of two or three.

They face the same set of challenges I described above, and I think that is where most of us actually work. A lot of the people I hear from are the only data person at their company.

The work is more hands on and less filtered through layers of decision making and process. Neither size is better, that is just the one I prefer.

What stood out about this group is what they wanted. Not someone to do the work for them, but a second set of eyes and advice while they keep ownership of the process. That shift was the most rewarding part of my year, and the direction I carried into 2026.

Related reading

• The Modern Data Viewpoint (3 Principles)
• The Business Case for Your New Data Architecture
• Can Small Data Teams Afford a "Modern" Database?
• Lessons Learned in 2022

Final takeaway

Looking back at 2025 from the teams I sat with that year, the tooling changed faster than the problems did. Naming, structure, consistency and knowing what you are actually trying to deliver were still the difference between a project that held together and one that did not.