Updated: 22 October 2026.
When every dashboard request requires somebody to create another table, view or permission manually, the warehouse becomes dependent on that person’s availability.
I would approach this as a delivery-process problem. The useful goal is to make an approved change repeatable, inspectable and recoverable, so another engineer can operate it.
Serverless infrastructure does not remove responsibility for schema design, access control or the meaning of the data.
Decide where the logic belongs
QuickSight supports custom SQL for suitable data sources and configurations. A database view is therefore a design choice, not a universal workaround for an absence of SQL support.
I would use a managed warehouse relation when several consumers need the same definition, when its permissions need central review or when it forms a stable reporting contract. A narrow experiment may belong closer to the analysis, provided its access is appropriate.
The decision should explain who owns the calculation and how a future change reaches its consumers.
Turn recurring requests into a small contract
For a fictional monthly headcount dataset, I would first define the fields, reporting period, inclusion rules, expected level of detail and permitted audience. Without that contract, automation can reproduce an ambiguous number very efficiently.
The proposed SQL, grants and accompanying explanation would live in version control. A reviewer should be able to see that a change adds a column, alters a calculation or expands access.
I would avoid an open-ended form that lets anybody submit arbitrary SQL under a powerful service identity. A controlled request can select an approved pattern and supply validated parameters instead.
A warehouse change needs execution checks, data checks and access checks before consumers rely on it.
flowchart TD
A["Dataset contract and SQL change"] --> B["Review SQL and grants"]
B --> C["Deploy in test environment"]
C --> D{"Statement completed successfully?"}
D -->|No| E["Investigate and correct"]
E --> B
D -->|Yes| F["Test data meaning and denied access"]
F --> G{"Checks pass?"}
G -->|No| E
G -->|Yes| H["Approved staged production deployment"]
H --> I["Verify result and record change"]
Give deployment its own workflow
My implementation would start in a test environment with synthetic or appropriately controlled data. The pipeline would validate the change, apply it with a restricted deployment identity and run checks before making the output available to consumers.
Redshift’s Data API can submit SQL, and its statement-status interface provides a way to check the result. A successful submission is not the same as successful execution. The workflow needs to wait for a terminal status and handle failure explicitly.
Retries also need design. I would use supported idempotency mechanisms where applicable and keep a deployment record, rather than assume that every SQL operation is safe to run twice.
Test meaning and permissions
For that headcount example, useful tests would cover the expected population, duplicate records, missing reporting periods and changes around a period boundary. The exact cases depend on the agreed definition.
Access tests belong in the same process. Can the reporting identity query the approved relation? Can it reach raw personal records it does not need? What happens to grants after an object is replaced?
For breaking changes, I would prefer a staged migration where existing consumers continue working while the new contract is tested. Some data changes cannot be undone by simply restoring the previous SQL file, so the recovery plan must fit the operation.
Make the process operable by somebody else
The deployment output should identify what changed, who approved it, the execution result and the checks performed. Failures need an owner and a documented response.
I would begin by automating one frequent, well-understood request. Once another engineer can deploy, verify and recover that change without private instructions, the pattern is ready to expand.
