How We Evaluated Snowflake, Databricks, and Redshift for a Regulated Data Platform
Turning user and operating requirements into testable PoC questions — not another feature comparison matrix
This article presents a generalized account of a data platform modernization project I worked on. It does not include the organization’s actual scores, costs, account structure, security policies, or test data. These products continue to evolve, so the observations below reflect the requirements and configuration of our PoC at that time — not a current or universal ranking.
This article is based on my own project experience and technical decisions. I used AI assistance to translate and polish the English wording.
When we began preparing for a data platform modernization project, I worked on a proof of concept comparing Snowflake, Databricks, and Redshift.
At first, it seemed that comparing product features and performance would lead us to the answer. But once I began turning our requirements into evaluation criteria, I realized we were asking the wrong question.
It was not:
Which product is the best?
It was:
Which platform best fits our users, control requirements, and operating model?
All three platforms could process data, run SQL, and manage access. But the way users experienced those capabilities — and the operational complexity behind them — varied. In a regulated environment, the presence of a feature alone was not enough to make a platform decision.
We started with users and the operating model
In our existing Hadoop environment, scheduled batch jobs, analysts’ ad hoc SQL, and data scientists’ preprocessing workloads shared limited infrastructure.
Modernization was not just about replacing aging hardware. We also wanted to isolate different workloads and create an environment where SQL-first users could work with data more easily.
At the same time, the company was increasing its investment in AI agents. Reliable agents require more than capable models. They also need accurate, current, and access-controlled data. The new platform therefore had to support both existing analytics and emerging AI use cases.
I collected requirements from data analysts and the team operating the existing platform, then translated security and financial-services compliance requirements into PoC criteria.
This led to a practical set of questions:
- Could SQL-first analysts use the platform without a steep learning curve?
- Could data engineers ingest and operate large-scale datasets reliably?
- Could compute be isolated and scaled independently by workload?
- Could we preserve our existing user-level access and masking controls?
- Could administrative work be delegated safely within a limited scope?
- Could we audit data access and permission changes?
- Could the platform connect to external tools and provide visibility into operations and cost?
These questions came before the feature matrix.
Figure 1. Requirements were translated into testable scenarios, evidence was classified by confidence, and findings were reported as trade-offs rather than a product ranking.
We evaluated both existing controls and a new delegation model
Access control could not be reduced to a checkbox asking whether a platform supported RBAC.
In our existing process, users requested read access to the tables required for their work. Access was granted only after approval.
Unmasking sensitive data required a separate approval scoped to the user and the target data. When the approved period or business purpose ended, the permission had to be revoked. The entire lifecycle — from request and approval to grant and revocation — also had to remain traceable.
For the new platform, we considered a project-based delegation model as well.
In the proposed model, when an analytics or ML project was created, a designated project administrator would be able to add or remove team members and manage read access to tables already approved for that project. The central platform and security teams would continue to own global policies and define the boundaries of delegation, without having to process every routine membership change themselves.
The goal was not simply to decentralize administration. It was to preserve central control while delegating repetitive tasks within clearly defined guardrails.
The PoC therefore examined whether each platform could support the following:
- Grant and revoke table access for individual users
- Apply an approved masking exception to a specific user
- Allow project administrators to manage members and read access within their own scope
- Prevent project administrators from affecting other projects or global policies
- Audit platform-side grants, changes, data access, and revocations, while retaining links to the external request and approval workflow
- Revoke project-related access reliably when a project ended
The detailed role hierarchy and masking implementation were outside the scope of the PoC. The PoC was not intended to lock in one detailed design. Its purpose was to determine whether each platform could meet these control objectives in an operationally manageable way.
We turned feature names into testable questions
I directly tested large-scale data ingestion across formats including CSV, fixed-width files, and Parquet. I also evaluated identity and access control, masking, audit logs, projected cost under defined assumptions, the analyst experience, external integrations, and monitoring.
I applied the same business and operational questions and examined how each platform could answer them.
- Data ingestion: Could the platform reliably process large-scale data across CSV, fixed-width, and Parquet formats?
- SQL usability: Could SQL-first analysts learn and use it easily?
- Access control: Could it reproduce our existing user-level table permissions in an operable way?
- Delegated administration: Could project administrators be restricted to managing only their approved scope?
- Data masking: Could masking controls, including user-specific exceptions, be applied consistently?
- Auditability: Could we trace permission changes and data access?
- Integration and monitoring: Could it connect to existing tools and provide visibility into errors and usage?
- Cost: Could cost be controlled under our expected workloads and usage patterns?
When documenting the results, I separated observations into three categories:
- Capabilities I configured and verified directly
- Concerns observed during testing that required further validation
- Areas that were not tested within the scope of the PoC
This distinction mattered. It helped us evaluate the products fairly and kept the final report credible.
What we observed across the three platforms
The following observations came from a limited PoC conducted at a specific point in time. They should not be treated as universal product conclusions.
Snowflake: the most natural experience for SQL-first users
The clearest advantage I observed in Snowflake was the experience it provided for SQL-first analysts.
Get Deukkyu Lee’s stories in your inbox
Join Medium for free to get updates from this writer.
Most of our core users queried and analyzed data through SQL, so adoption speed was an important consideration. In the environment I tested, Snowflake felt the most natural for this group.
Its model for separating compute by workload also aligned well with our goal of isolating analytics, batch processing, and ad hoc workloads.
Projected cost remained an important trade-off under our workload and usage assumptions. The usability advantage did not remove the need for active cost management. If we selected the platform, workload isolation, compute sizing, auto-suspend, and cost monitoring would all need to be part of the operating model.
Databricks: a strong fit for data engineering, with different adoption needs
Databricks felt familiar because it aligned closely with the Spark-based data engineering workflow I was already using.
From the perspective of analysts who primarily worked in SQL, however, the configuration we tested appeared to require more onboarding and support than Snowflake.
MLOps was an important area of interest, but it was not part of the PoC work I performed directly. I therefore excluded it from the verified comparison rather than presenting it as a tested result.
Redshift: AWS familiarity with an additional permission boundary
Redshift was familiar because of its integration with the broader AWS ecosystem.
When querying external data in Amazon S3 through Spectrum, however, the architecture had to coordinate an AWS IAM role used by Redshift for S3 and external-catalog access with database permissions inside Redshift.
This did not mean that every analyst needed a separate IAM identity. The concern was that, within the operating model we were evaluating, the relationship between the two permission boundaries introduced another area that had to be designed, managed, and audited.
The masking implementation we tested also required further design validation against our requirements. This does not mean that Redshift lacked masking capabilities. The open question was how much operational complexity would be introduced when applying our user-specific approval and revocation process together with the proposed project-level delegation model.
We translated technical results into decision language
My role did not end with configuring and testing product features.
It was equally important to turn the findings, limitations, and untested risks into a report that decision-makers could use.
The report focused on questions such as:
- Could our main users work with the platform effectively?
- Could we preserve existing access and masking controls?
- Could we operate limited, project-level delegation safely?
- How much complexity would fall on the platform and security teams?
- What additional control boundaries would appear when connecting external systems?
- Could we control cost under the usage model we expected?
- What risks still required validation before implementation?
Snowflake was ultimately selected as the core data platform.
Because our primary users were SQL-first analysts, analyst usability had the greatest influence on the decision. We also assessed each platform’s ability to support our access-control, operating-model, and external-integration requirements. Cost was treated as a trade-off that would require active management after adoption.
This decision did not mean that Snowflake was superior in every area.
Large-scale ingestion and transformation, SQL analytics, and data serving are different workloads. After the platform decision, we continued refining the architecture by combining compute engines and storage formats according to the role each needed to perform.
The goal of the PoC was not to create an absolute ranking of three products. It was to decide which platform should take responsibility for which part of our environment.
What I learned
Start with the work people actually do
Evaluation criteria should begin with users and operating processes, not a vendor feature matrix.
How easily analysts could use SQL, how much authority a project administrator could receive, and whether the security team could audit permission changes mattered more than the number of features on a product page.
Access control is a lifecycle
Access control does not end when a permission is granted.
Request, approval, grant, use, expiration, and revocation all belong to the same lifecycle. In a regulated environment, it is not enough to know who can receive access. We also need to know who received it, why it was approved, when it became active, and when it was removed.
Feature availability and operational fit are different questions
Most platforms provide the required capabilities in some form.
What differs is the complexity of adapting those capabilities to an organization’s identity model, approval process, and operating team. A feature can exist and still be difficult to operate under a specific control model.
An observation is not a universal product judgment
A cost estimate based on one usage model or a usability observation from a limited environment should not be presented as a permanent property of a product.
Separating verified results, unresolved concerns, and out-of-scope areas made the decision more trustworthy.
Closing thoughts
The most valuable result of this PoC was not the product ranking.
The more important work was translating user and operational requirements into testable questions, separating confirmed facts from remaining uncertainty, and explaining the technical results as trade-offs that decision-makers could understand.
That is also close to how I think about the role of a Solution Architect.
It is not enough to know the technology. The job is to understand user needs and operating constraints, turn them into a structure that can be tested, and help an organization make a better decision.
In the next article, I plan to explain how we evaluated Apache Iceberg Merge-on-Read while considering data movement and write performance under a fixed network constraint in a hybrid environment.
