A data warehouse that scales automatically can still disappoint its users and surprise its finance team. An executive dashboard may slow down during the morning reporting rush, while a large transformation job consumes capacity that no one budgeted for. The problem is not necessarily a shortage of compute. It is the absence of an agreed business outcome for that compute.
Amazon Redshift Serverless now offers a more explicit way to make that trade-off. On April 27, 2026, AWS announced that AI-driven scaling and optimization became the default for new Serverless workgroups, with support expanded to a base-capacity range of 8 to 512 Redshift Processing Units (RPUs). The change makes predictive scaling more accessible, but it does not replace the need for workload measurement, spending controls, or performance ownership.
The useful executive question is not “How many RPUs should we buy?” It is “What response time must our critical analytics deliver, how much variability can we accept, and what is that worth?” This guide shows how to turn that question into a measurable Redshift configuration and operating process.
What changed in Redshift Serverless in 2026?
The April 27 AWS release announcement describes a system that learns from workload patterns and adjusts compute in anticipation of demand, considering factors such as query complexity, data volume, and estimated scan size. It also describes automatic optimization of physical design and materialized views. New Serverless workgroups use AI-driven scaling by default, with a Balanced price-performance target that can be changed later.
The supported AI-driven base-capacity range of 8 to 512 RPUs matters for smaller environments that previously faced a higher entry point. Do not confuse that range with every possible Serverless base-capacity setting: AWS documentation also describes a 4-RPU configuration with distinct restrictions, and higher regional maxima in some locations. Confirm eligibility, workgroup settings, and regional limits before planning a change.
AWS’s compute-capacity guide explains the workgroup-specific price-performance slider. Its main choices prioritize cost, balance cost and speed, or prioritize performance, with intermediate settings available. The slider expresses a preference, not a fixed service-level guarantee or a promise of a specific monthly bill.
Start with the business service level, not the RPU number
An executive BI workload usually contains several very different jobs. A CEO might open a revenue dashboard at 9 a.m.; a finance team might run an end-of-day reconciliation; analysts may explore large tables unpredictably; and scheduled ingestion may run while all of this is happening. Treating every query as equally urgent leads to a misleading average.
Define the service level for each important workload before tuning. For a board-facing dashboard, measure how quickly the complete dashboard becomes usable, not merely the database’s execution time for one SQL statement. For a data pipeline, measure when trusted data becomes available relative to its business deadline. For ad hoc analysis, agree on a reasonable responsiveness band rather than an unrealistic guarantee.
A practical service-level register
For each workload, record its business owner, user population, peak window, refresh frequency, baseline median and 95th-percentile duration, permitted failure rate, data freshness requirement, and monthly cost allocation. Add a severity level for missed deadlines. This register becomes the acceptance test for any capacity or optimization decision.
For example, a sales dashboard might require its principal visuals to load within eight seconds at the 95th percentile during the 8:30-10:00 a.m. reporting window. A nightly consolidation might instead need to finish before 6 a.m. These are illustrative targets, not Redshift benchmarks. Your own thresholds should come from business needs and measured user experience.
Understand the three controls that shape the result
1. Base capacity establishes the starting point
Base RPUs describe the compute capacity configured for the workgroup. Higher base capacity can help complex joins, wide tables, and large scans, but raising it indiscriminately can increase compute consumption. Some configurations also have storage and table-width restrictions. In particular, the smallest supported configurations are not interchangeable with larger warehouses.
Choose a base capacity that accommodates normal operations and satisfies technical limits. Do not size the entire environment for the single worst historical query. Investigate whether that query is inefficient, whether it should run in a different window, and whether it is business-critical before treating it as the sizing reference.
2. The price-performance target sets the optimization preference
A cost-oriented target may tolerate longer query runtimes when the system predicts that additional scaling would not be economical. A performance-oriented target can scale more aggressively and may increase cost. Balanced is the documented default for new workgroups and a reasonable starting point for many mixed workloads, but its suitability must be tested against your service levels.
The correct setting can differ by workgroup. A customer-facing reporting endpoint may justify a different preference from an internal experimentation environment. Avoid using a single enterprise-wide setting simply because the warehouses share a cloud account.
3. Limits and alarms keep elasticity accountable
Scaling is not a budget policy. Set appropriate workgroup usage limits in RPU-hours and choose whether breaches should be logged, trigger an alert, or stop user queries. The last option is disruptive and should be reserved for environments where a hard stop is acceptable. AWS documents these controls in its Serverless usage-limit guidance.
Also review the maximum RPU capacity the workgroup can allocate, and track charges beyond compute, including managed storage and relevant data transfer. An RPU-hour limit protects only the scope of the configured limit. It is not a substitute for an account-level cost budget or an accurate understanding of the billing model.
Build a benchmark that represents real work
A useful benchmark captures a complete business cycle, not a handful of synthetic SELECT statements. Include scheduled refreshes, BI-tool concurrency, parameterized dashboard filters, ETL or ELT transformations, and the long-running queries that create contention. If the workload varies by weekday or month-end, test those patterns separately.
Step 1: Establish a clean baseline
Record the existing base capacity, price-performance setting, usage limits, data volume, schema design, materialized views, and workload schedule. Capture at least one representative reporting cycle. Keep track of cache effects, BI application behavior, and changes in upstream data freshness, so a faster result is not mistakenly credited to compute scaling.
Measure p50 and p95 query duration by workload group, throughput during peak periods, failed or canceled queries, dashboard completion time, ingestion lag, and daily RPU-hours. Cost per successful business outcome is often more useful than raw compute hours: a cheaper warehouse is not a win if it regularly misses the finance close.
Step 2: Segment queries by business purpose
Tag or classify recurring queries where possible. Distinguish interactive dashboards, scheduled reports, transformations, exploratory analysis, and operational integrations. Use query identifiers, application context, time windows, and normalized SQL patterns to connect technical events to a business function. Avoid exposing sensitive SQL text unnecessarily in widely shared monitoring reports.
Redshift’s SYS_QUERY_HISTORY view provides query timing and status information, while SYS_SERVERLESS_USAGE summarizes Serverless compute usage at one-minute granularity. The latter retains seven days of data, so export or aggregate the measures into a longer-lived monitoring store if you need month-over-month evidence. Access to the usage view is restricted, so design an appropriate governed reporting path.
Step 3: Test settings one variable at a time
Compare the baseline with a cost-oriented target, Balanced, and a performance-oriented target while holding data, query mix, and concurrency as consistent as practical. Repeat important tests, because predictive scaling learns from workload history and the first run may not reflect steady-state behavior. Do not change base RPUs, query design, BI refresh schedules, and the slider simultaneously if you want to know which change helped.
When changing base capacity, schedule carefully. AWS notes that editing this setting can cancel running queries. Capture the previous configuration and a rollback procedure, and notify business owners if a test affects shared production workloads.
Step 4: Evaluate the whole cost-performance frontier
Plot each candidate configuration against at least two outcomes: business-service-level attainment and total attributable compute usage. A setting that reduces average latency but still misses the morning p95 target may not be worth the additional spend. Conversely, a setting that saves RPU-hours but delays a time-sensitive reconciliation may be operationally expensive.
Keep the comparison anchored to the same workload window and data volume. Show confidence ranges or run-to-run variation rather than presenting a single test as conclusive. Separate true improvements from changed query mix, dashboard caching, and lower user concurrency.
An illustrative example: the Monday morning dashboard rush
Consider a hypothetical distributor with 60 dashboard users, a daily order load, and a finance reconciliation job. Its main dashboard normally completes in six seconds, but during the Monday morning rush its 95th-percentile load time rises to 22 seconds. A nightly transformation sometimes overlaps with the first wave of users. The company wants p95 below 10 seconds without letting warehouse spend drift upward unchecked.
The team first instruments the complete dashboard experience, including network and visualization time. It identifies the most expensive SQL patterns, verifies that the underlying data is fresh, and checks whether the transformation can finish earlier. It then runs representative tests with Balanced and a more performance-oriented setting, retaining the same query mix and monitoring RPU-hours.
Suppose the performance-oriented test reaches a p95 of nine seconds but consumes more compute, while Balanced reaches 11 seconds at lower cost. Those figures are hypothetical, not a customer result or a claim about Redshift. The decision now becomes explicit: is the extra spend justified to meet the 10-second service level, or can query and scheduling improvements close the remaining gap?
This framing helps a COO and finance leader approve a policy rather than a vague infrastructure upgrade. The chosen configuration can be reviewed monthly against the same dashboard experience, workload mix, and spend measures.
The metrics an executive dashboard should actually show
Performance and reliability
Report p50 and p95 dashboard load time for critical dashboards, p95 database query duration for their underlying workloads, throughput at peak concurrency, failed or canceled query counts, and the percentage of scheduled reports delivered on time. Separate user-facing performance from database execution time so that a slow visualization layer is not blamed on the warehouse.
Capacity and scaling behavior
Track base RPUs, observed compute capacity, time spent at elevated capacity, and the frequency of peak demand. AWS identifies the ComputeCapacity metric in CloudWatch and the compute_capacity field in SYS_SERVERLESS_USAGE as ways to inspect scaling. Overlay the usage curve with dashboard activity and scheduled processing to identify predictable contention.
Cost and unit economics
Show daily and monthly RPU-hours, compute cost using the applicable regional rate and billing terms, storage cost separately, and the cost per successful refresh or completed reporting cycle. Track cost per 1,000 successful dashboard executions only if query attribution is reliable; otherwise label the number as an allocation estimate rather than a precise bill.
A useful executive view contains a target, current result, trend, owner, and decision trigger for every metric. For instance: “If dashboard p95 exceeds the agreed threshold for three business mornings, investigate query regressions and capacity behavior before changing the slider.” A graph without an escalation rule is monitoring, not management.
Use a simple, auditable cost model
The basic compute unit is the RPU-hour. At a simplified level, compute charge equals billable RPU-hours multiplied by the applicable regional RPU-hour rate, subject to the AWS pricing terms and any relevant discounts or commitments. For a period of varying capacity, estimate RPU-hours by summing each interval’s capacity multiplied by its billable duration in hours.
As an arithmetic illustration, 32 RPUs used for two billable hours equal 64 RPU-hours. At an assumed rate of $0.40 per RPU-hour, that would be $25.60 in compute charges. The rate is purely illustrative and is not an AWS quote. Actual billing can include additional services and storage, and the applicable rate depends on region and commercial terms.
Avoid multiplying base RPUs by every hour of the month and calling that the Serverless bill. Redshift Serverless billing depends on actual metered activity under its pricing rules, not a simplistic always-on capacity reservation. Use the AWS pricing page and your billing data as the financial source of truth.
Where automatic scaling does not solve the problem
Inefficient SQL remains inefficient SQL
A query that scans far more data than necessary may still be costly after scaling. Review join cardinality, filters, sort and distribution behavior, repeated subqueries, and opportunities for pre-aggregation. Query tuning can reduce both latency and spend, while an aggressive scaling target may simply accelerate waste.
Poor data modeling can dominate the dashboard experience
If the semantic layer creates inconsistent metric definitions or a BI tool issues dozens of redundant queries, additional compute will not repair the reporting design. Consider shared measures, reusable models, appropriate aggregations, and selective materialization. Actiknow’s business intelligence and reporting services describe the wider work of turning data into decision-ready reporting, beyond infrastructure settings.
A data freshness problem is not a compute problem
A dashboard can load quickly while showing yesterday’s data. Measure ingestion completion, transformation success, reconciliation status, and freshness separately. If a pipeline is delayed by upstream API limits or a failed connector, more Redshift compute may not help. For a business-critical report, publish freshness status alongside performance.
Uncontrolled concurrency can obscure the cause
A few expensive exploratory queries may overlap with a time-sensitive reporting window. Before raising capacity, consider scheduling, workload isolation, query optimization, or separate workgroups where the operating model warrants them. Test whether these changes improve the critical service level at lower cost than a more aggressive price-performance target.
A four-week implementation plan
Week 1: Inventory and agree on outcomes
List workgroups, BI tools, upstream pipelines, recurring jobs, data volumes, owners, and reporting deadlines. Confirm the current AI-driven scaling setting, base capacity, and limits. Select two or three critical workloads and agree on p95 latency, freshness, reliability, and spend thresholds. Define the measurement period and the business owner who can approve trade-offs.
Week 2: Instrument the baseline
Collect Redshift system-view data, CloudWatch metrics, BI application timings, and AWS billing information. Reconcile the measures to known reporting windows. Build a compact operational dashboard and validate its numbers with both engineering and finance. If the monitoring dataset requires longer retention, schedule a governed extraction rather than relying indefinitely on the seven-day usage view.
Week 3: Run controlled comparisons
Test representative peak and non-peak workloads under selected price-performance targets. Keep the test matrix small enough to interpret. Capture median and tail latency, query failures, RPU-hours, and data freshness for each run. Note configuration changes and unusual business events. Test rollback and verify that alert recipients understand the usage-limit actions.
Week 4: Select a policy and operationalize it
Choose the lowest-cost configuration that meets agreed service levels with an appropriate safety margin. Document why it was selected, what evidence supports it, and when to reconsider. Add automated alerts, a monthly performance-cost review, and change-control checks for major schema, dashboard, or ingestion changes. Assign ownership for both the warehouse and the business metrics.
Governance and security checks before production
Restrict who can change workgroup capacity, price-performance targets, and usage limits. Record configuration changes in your normal infrastructure change process. Review IAM permissions for monitoring integrations and avoid granting broad system-view access to dashboard consumers. Aggregate or mask operational data when query text, user identifiers, or business-sensitive workloads could be exposed.
Separate test and production workgroups where feasible. Define a change window for capacity adjustments, a rollback path, and a business communication plan. Establish alarms for both technical failure and service-level breaches. A cost cap that silently turns off user queries can be more damaging than the spending it prevents, so match enforcement actions to operational criticality.
A decision framework for CIOs and finance leaders
Ask five questions before approving a scaling change. First, which business workflow is failing, and how is failure measured? Second, is the root cause query design, concurrency, upstream data, or compute capacity? Third, what improvement did a controlled test demonstrate? Fourth, what is the incremental cost per successful outcome? Fifth, who owns monitoring and rollback after the change?
If those questions cannot be answered, retain the current configuration and improve measurement first. If the evidence is clear, choose the setting that meets the business objective with the smallest defensible total cost. The goal is not maximum elasticity. It is predictable decision-making under variable demand.
Frequently asked questions
Is AI-driven scaling enabled automatically in Redshift Serverless?
AWS made AI-driven scaling and optimization the default for new Serverless workgroups on April 27, 2026. Existing workgroups should be inspected individually rather than assumed to have the same configuration. Check the workgroup’s performance settings and the AWS documentation for your region and configuration.
What is an RPU in Redshift Serverless?
An RPU, or Redshift Processing Unit, is a measure of Serverless compute capacity. AWS documents one RPU as providing 16 GB of memory. The number of RPUs affects the resources available to execute workloads, but performance also depends on SQL, data layout, concurrency, and application behavior.
Should we start with Balanced or Optimizes for Cost?
Balanced is the default for new workgroups and a sensible benchmark for mixed workloads. A cost-oriented target may suit less time-sensitive processing, but only if it meets the required deadlines. Compare the settings against representative workloads rather than selecting one solely from its label.
Does AI-driven scaling guarantee faster dashboards?
No. It can allocate compute more intelligently, but it does not guarantee a particular end-user response time. BI rendering, caching, network latency, data modeling, inefficient SQL, and upstream data delays may remain bottlenecks. Test the complete user journey.
Will a higher base RPU always cost more?
Not necessarily for every workload. A larger configuration may complete some work faster, and billing depends on metered consumption. However, a higher base can also increase spend. Compare billable RPU-hours and service-level attainment for the same workload before making a decision.
Can we set a hard monthly spending limit?
Redshift Serverless supports workgroup RPU-hour usage limits with logging, alerts, or an action that turns off user queries. These are operational controls, not a complete cloud-spend guarantee. Storage, data transfer, and other AWS charges require separate monitoring and budgeting.
How do we see whether Redshift scaled up?
Review the Redshift console’s RPU-capacity graph, the CloudWatch ComputeCapacity metric, and relevant SYS_SERVERLESS_USAGE records. Correlate capacity changes with SYS_QUERY_HISTORY and application-level reporting windows. Ensure the monitoring identity has the required permissions.
How long should we benchmark before changing the target?
Cover the business patterns that matter, including peak reporting, batch processing, and any month-end activity. A single fast test is insufficient. Because the optimizer learns from workload history, repeat comparisons over representative periods and record the workload mix.
Can we use the same target for every workgroup?
You can, but it is rarely a good governance rule. AWS defines price-performance targets per workgroup. A time-sensitive executive dashboard and a low-priority development workload may warrant different cost and responsiveness trade-offs.
When should we consider query optimization instead of scaling?
Start with query and model optimization when a small set of expensive queries dominates consumption, when BI tools issue redundant SQL, or when data is scanned unnecessarily. Scale when the measured bottleneck is resource availability under legitimate demand and the incremental cost is justified.
The bottom line
Redshift Serverless AI-driven scaling makes compute allocation more adaptive, but it does not decide what good performance is worth to your business. Establish service levels, instrument real workloads, compare price-performance targets under controlled conditions, and govern the outcome with usage limits and clear ownership.
If your organization needs to connect warehouse performance to executive reporting outcomes, Actiknow’s custom BI dashboard development can support the reporting and measurement layer. For a focused discussion about workload visibility, data integration, or BI requirements, talk with Actiknow about your analytics requirements.
Official technical references
For product behavior and configuration details, consult the AWS release announcement, the AWS compute-capacity guide, the AWS Serverless monitoring guide, and the AWS usage-limit documentation. Validate regional pricing and limits against your own AWS account before changing production settings.