Part 1 of a 4-part series on Redshift and the modern data platform: Part 2: Agentic AI Needs a Work Record (publishes October 14) · Part 3: Cheaper Models Make the Data Platform Matter More (publishes October 16) · Part 4: Exploration Is Not the Same as Production (publishes October 19)

Picture the meeting. Two vendors, two pitches.

The first vendor promises you will never think about infrastructure again. No knobs, no tuning, no visibility either. The bill arrives monthly and good luck explaining it.

The second vendor hands you a cluster, a 400-page operations guide, and wishes you luck. Total control, total responsibility. Your analysts just wanted to run queries. Now they are platform engineers.

If you have sat in that meeting, you know how it ends. The team picks one, regrets it within a year, and starts evaluating the other.

Most enterprises live somewhere in the middle. They want reliable answers, strong governance, good performance, predictable cost, and enough flexibility to evolve without building a second infrastructure organization inside analytics.

That is why I think Redshift has become more interesting lately. Not because it “won” the warehouse war. Because it evolved into something more pragmatic: a balanced analytics platform that fits how most organizations operate.

For readers outside the AWS world: Redshift is Amazon’s data warehouse, around since 2013. It stores massive datasets and answers SQL queries fast using Massively Parallel Processing. It is the system behind a lot of dashboards and reports you have seen without knowing it.

What the middle looks like

Redshift gives teams SQL-first workflows, strong performance, lower-cost analytics at enterprise scale, AWS-native governance, S3 integration, open table format interoperability, streaming ingestion, federated access, lakehouse capabilities, and serverless deployment options.

But it also preserves something important: operational familiarity.

Most enterprises already understand SQL, IAM, S3, BI tooling, dbt workflows, governance models, cost allocation, and infrastructure ownership. Redshift fits those operating models without forcing organizations to reinvent themselves around the platform.

And when teams are being asked to do more with less, that combination of performance, governance, familiarity, and lower cost matters more than raw benchmark wars.

dbt changed the equation too. When models, governance, testing, and documentation sit above the engine, the warehouse becomes part of a broader ecosystem instead of the center of the universe. The future probably does not belong to one magical proprietary engine. It belongs to platforms that integrate cleanly into composable ecosystems.

The storage layer is moving the same direction

Here is what convinced me this is a direction, not a moment. Last week AWS announced that S3 Tables now support all Apache Iceberg V3 data types: variant columns for semi-structured data, nanosecond timestamps, geometry and geography types, deletion vectors, and row lineage.

S3 Tables is storage that manages itself. You get Iceberg tables on S3 with automatic compaction and snapshot management handled for you. No small-files problem to babysit. No maintenance windows to schedule.

That is the same middle ground, one layer down. Teams get open table formats and multi-engine access without taking on the operational burden of running the table infrastructure themselves. Managed where it should be, open where it matters.

Let the workload speak

One habit I keep coming back to, including in my AWS Summit DC talk on letting your database speak: workload shape should drive architecture decisions, not the other way around.

Watch a Redshift cluster over a day. Ingestion jobs land early. Dashboards refresh on schedules. Analysts explore ad hoc. Batch jobs run overnight. Query history shows where those workloads compete. Queue wait times show pressure windows. Skew shows wasted compute.

That evidence is the whole game. It tells you whether shared capacity still meets your SLOs or whether a workload has earned its own isolated compute. It is the same evidence-driven thinking behind the newer RG direction: more optimization moving into the platform, less manual tuning, while teams keep visibility and control.

What we optimized for five years ago is not what we would optimize for today. Redshift has steadily reduced the tuning burden as patterns changed, and capabilities like extra compute for automatic optimizations are good examples of that evolution.

A note on fit

Redshift is not something you should treat like a generic transactional database. Teams that understand workload patterns, data layout, and query behavior know that. If the use case is a traditional relational workload, Postgres is often the better answer.

For many organizations, Redshift remains a useful balance: SQL-first analytics, AWS-native governance, performance, cost visibility, and enough operational control to avoid turning the warehouse into a black box.

Why this matters now

AI makes the foundation question more important, not less. AI systems are increasing heterogeneity across vector retrieval, streaming, event-driven pipelines, object storage, real-time inference, warehouse analytics, governance, semantic layers, and agents.

And agents change the workload profile. Human analysts ask questions in bursts. Agents can run 24x7. They are goal-seeking. They ask different questions, explore paths, retry, inspect, summarize, validate, and trigger follow-up actions.

That makes agentic AI an additional layer of activity on top of human analyst-driven workloads.

So the foundation matters.

Performance matters. Governance matters. Cost matters even more.

That is where Redshift’s trajectory feels strategically important. Not because it tries to replace everything. Because it provides a strong, cost-efficient foundation for analytical, operational, and increasingly agentic workloads across the AWS ecosystem.

Next: Part 2 — Agentic AI Needs a Work Record (publishes October 14), on the night an agent changed the numbers and nobody could say why.

References