Information Technology

Data Warehouse RFP Template (Free): Requirements and Scoring

Paste-ready data warehouse requirements (ELT and streaming ingestion, workload isolation, open table formats, governance, cost controls), sharp vendor questions and a weighted scoring rubric.

14 pages Microsoft Word ★ 5 of 5 93 downloads Updated October 5, 2026
Download Template
Data Warehouse RFP Template (Free): Requirements and Scoring

Preview the first pages

See the structure before you download. The Word file has every section listed below, ready to fill in.

Open preview Give feedback

What's inside

The sections in the document, in order.

  1. How to run a Data Warehouse RFP
  2. Data warehouse vs lakehouse: what to ask for in the RFP
  3. Data Warehouse RFP requirements
  4. Questions to ask Data Warehouse vendors
  5. Scoring rubric
  6. Frequently asked questions
  7. Related RFP templates

Use this data warehouse RFP template when you're moving an on-premises warehouse to the cloud, consolidating separate data marts, or choosing a cloud data platform for analytics, BI and data science.

It's written for the data, analytics and procurement team running the evaluation, and it covers the whole process: the workload profile vendors should price against, the requirements to send, the questions that separate vendors, and how to score the answers.

What’s inside this template

  • A step-by-step plan for running the evaluation, from profiling your workloads to a proof of concept on your own data
  • Requirements for SQL, semi-structured data, ELT and streaming ingestion, workload isolation, open table formats, data sharing and governance, each marked Must-have or Nice-to-have
  • Questions that expose background compute costs, limits on open-format tables, gaps in policy enforcement and preview-only AI features
  • A weighted scoring rubric with 1-to-5 definitions, plus pricing requirements that put consumption and capacity models side by side
  • An editable Word RFP with response codes, a pricing table and a timeline

Download the editable Microsoft Word version below. Every requirement, vendor question and scoring weight on this page is in the document, ready to tailor and send.

How to run a Data Warehouse RFP

A data warehouse evaluation turns on your workloads: which data, which queries, how many users and how fresh the data must be. The example schedule below runs about 14 weeks from kickoff to contract award; stretch it if you're migrating a large warehouse with years of stored procedures and ELT jobs.

  1. Profile your workloads and agree on scope (weeks 1-3). List the data sources, current data volumes and expected growth, how fresh each source must be, and the main workloads: ELT, BI dashboards, ad hoc analysis, data science and data sharing. Record the figures vendors will price against, including peak concurrent users, and pick a set of representative queries, dashboards and pipelines to reuse in the proof of concept.
  2. Assemble the buying team. Include data engineering, analytics and BI, data science, cloud platform, security and privacy, plus finance, procurement and legal. Bring finance in early: with consumption pricing, cost depends on how the platform is used, so budgets and cost controls belong in the requirements, not in a later clean-up.
  3. Settle the architecture, and decide whether you need an RFI (weeks 2-4). Decide which cloud provider and regions you need, whether data must stay in open table formats in your own storage, and how you'll handle the warehouse-versus-lakehouse question (see below). If the architecture is still open, or your long list has more than five vendors, issue a short RFI first and use the answers to build a shortlist.
  4. Tailor and issue the RFP (weeks 4-7). Delete requirements that don't apply, adjust priorities, and add your workload profile to Section 1 so every vendor prices the same scenario. Give vendors three weeks to respond, with a written question-and-answer window in the first week.
  5. Score the responses (weeks 7-8). Have each evaluator score independently against the rubric before comparing notes, and set aside any vendor that misses a Must-have. Check every 'yes' for whether the feature is generally available today, and which edition it needs.
  6. Run a proof of concept with two or three vendors (weeks 8-12). Load a masked copy of real data, then run your representative queries, an ELT pipeline and a concurrency test. Check that masking and row-level policies hold inside your BI tool, record the compute each test consumed, convert a sample of your stored procedures, and call references with a similar workload.
  7. Negotiate and award (weeks 12-14). Recalculate the three-year cost from the usage measured in the proof of concept, and size any commitment to it. Settle renewal caps, the treatment of unused commitment, and exit and data-export terms before you sign, not after.

Data warehouse vs lakehouse: what to ask for in the RFP

A data warehouse stores data in the platform's own managed format and is built for SQL analytics and BI. A data lakehouse keeps data in open formats in cloud object storage, typically Apache Parquet files managed as Apache Iceberg or Delta Lake tables, so SQL engines, Spark jobs and machine learning tools can all work on the same copy. Both designs can separate storage from compute, so you scale and pay for each independently.

The two now overlap. Warehouse platforms can query, and often write, open table formats, and lakehouse platforms provide SQL engines, governance and BI connectivity. Rather than asking vendors which category they belong to, specify the capabilities you need and test them in the proof of concept.

Native warehouse storage suits teams whose main workloads are SQL, BI and reporting and who want the platform to handle storage layout and tuning. An open-format approach suits teams that run several engines on the same data, hold large volumes of raw or semi-structured data, or want their data to stay in their own storage account to limit lock-in. You can also combine them, with open-format tables for raw and shared data and native tables for heavily used BI models.

Questions to include either way:

  • Can the platform read and write Apache Iceberg or Delta Lake tables in our own object storage, and which features are limited on those tables compared with native tables?
  • Which catalog manages open-format tables, and can other engines read and write through it (for example, through the Apache Iceberg REST catalog interface)?
  • Do access policies, masking and lineage apply equally to native and open-format tables?
  • How do our representative queries perform on open-format tables compared with native tables? Test this in the proof of concept.
  • Who handles table maintenance (compaction, snapshot expiry, small-file cleanup), and what compute does it consume?
  • Are storage and compute billed separately, and can several compute engines share one copy of the data?

Data Warehouse RFP requirements

Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.

Functional

ID Requirement Priority
F1 ANSI-standard SQL, including window functions, common table expressions and MERGE for incremental loads and slowly changing dimensions, plus SQL stored procedures and user-defined functions. List notable deviations from the standard. Must-have
F2 Native storage and querying of semi-structured data (JSON at minimum, plus Avro, Parquet and ORC) without defining a fixed schema first, with SQL functions to flatten nested arrays and objects. State whether XML is supported. Must-have
F3 Bulk loading from our cloud object storage in CSV, JSON, Parquet, Avro and ORC, and continuous loading that picks up new files automatically as they arrive. Must-have
F4 Streaming ingestion from our event-streaming platform [name] or through a streaming API, with rows queryable shortly after they are published. State the typical latency and how streaming ingestion is priced. Must-have
F5 In-platform (ELT) transformation: scheduled SQL tasks, dependency-aware pipelines, and tables or materialized views that refresh incrementally as source data changes. Must-have
F6 Querying and restoring data as it existed at an earlier point within a configurable retention period (time travel), and recovery of dropped tables and schemas. Must-have
F7 Instant copies (clones) of databases, schemas or tables for development and testing that don't duplicate storage until the data changes. Nice-to-have
F8 Live, read-only sharing of selected tables and views with other accounts, business units or external partners without copying or exporting the data, with access we can revoke at any time. State whether recipients on other platforms can read shared data. Must-have
F9 A natural-language interface that turns business questions into SQL, shows the generated SQL, and respects the user's existing access permissions. Nice-to-have
F10 SQL functions that apply large language models to text in tables (for example, summarizing, classifying or extracting fields), and a vector data type with similarity search. State which models are available and where they run. Nice-to-have

Technical and architecture

ID Requirement Priority
T1 Separation of storage and compute, so query capacity can grow or shrink without moving data, and storage and compute are sized and billed independently. Must-have
T2 Elastic or serverless compute that scales on demand, suspends automatically when idle and resumes on the next query. State the minimum billing increment and the typical resume time. Must-have
T3 Workload isolation: separate compute for different workloads (for example, ELT, BI dashboards and data science) on the same data, so one workload can't slow another down. Must-have
T4 Automatic handling of concurrency peaks by adding compute or by queuing with priorities, plus query timeouts and limits on runaway queries. State the concurrency limits per compute unit and how scaling is triggered. Must-have
T5 Columnar storage with compression, parallel query execution, result caching and materialized views, plus clustering, partitioning or sort keys that reduce the data each query scans. Provide query profiles that show where time and resources are spent. Must-have
T6 Querying of tables stored in an open table format (for example, Apache Iceberg or Delta Lake) in our own cloud object storage, so other engines can use the same data without copies. State the formats and versions supported, and any limits compared with native tables. Must-have
T7 Writing to and maintaining open-format tables (compaction, snapshot expiry), and exposing them to other engines through an open catalog interface such as the Apache Iceberg REST catalog. Nice-to-have
T8 A fully managed service in [cloud provider(s)] and [regions], with our data and backups kept in the regions we choose. State whether you also offer deployment on other clouds, in our own cloud account or on premises, and what differs. Must-have
T9 Replication of selected databases to a second region, with a documented failover and failback procedure. State the recovery point and recovery time objectives you support. Must-have
T10 Cost controls and usage visibility: budgets and spending alerts by account, team or workload; automatic limits or suspension when a budget is reached; and compute and storage usage attributed to each workload, team, user and query (for example, through tags). Must-have

Integration

ID Requirement Priority
I1 Single sign-on with our identity provider via SAML 2.0 or OIDC, with user and group provisioning via SCIM. Must-have
I2 JDBC and ODBC drivers, and supported connectors for our BI tools [list] for both live queries and extracts. State which connectors you maintain and which are maintained by the BI tool's vendor. Must-have
I3 Change data capture (CDC) from our operational databases [list], either built in or through a supported partner tool. State which, and whether deletes and schema changes are carried through. Must-have
I4 Supported connectivity for our data integration, transformation and orchestration tools [list], including open-source SQL transformation frameworks. Must-have
I5 Python and Apache Spark connectivity for data science notebooks, with the same access controls and masking as SQL users. Must-have
I6 A dataframe API that runs Python processing inside the platform, and training or scoring of machine learning models without exporting data, or integration with our ML platform [name]. Nice-to-have
I7 A documented API, command-line tools and infrastructure-as-code support (for example, a Terraform provider) for managing users, roles, compute and database objects, so changes can go through our CI/CD pipeline. Must-have
I8 Export of login, query, data-access and administrative audit logs to our SIEM, and of usage and cost data to our monitoring or FinOps tools, in a documented format. Must-have

Security and compliance

ID Requirement Priority
S1 A current SOC 2 Type II report and ISO/IEC 27001 certification covering the proposed service, available under NDA. Must-have
S2 Support for regulated data: a HIPAA business associate agreement, PCI DSS attestation, or FedRAMP authorization at the required impact level. Make the relevant item Must-have if it applies to you. Nice-to-have
S3 Isolation of our data from other customers, and encryption at rest (AES-256 or equivalent) and in transit (TLS 1.2 or later). Must-have
S4 Customer-managed encryption keys held in our cloud key management service, with the ability to revoke access to our data. State which editions include this. Nice-to-have
S5 Private network connectivity from our cloud network to the service, IP allowlists or network policies, and the option to block access from the public internet. Must-have
S6 Role-based access control with custom roles and inherited privileges, MFA for all human users, and key-based or OAuth authentication for service accounts instead of passwords. Must-have
S7 Fine-grained access control: row-level security, column-level security and dynamic data masking based on the user's role, defined once and enforced in every tool, API and share. Must-have
S8 Automatic discovery and classification of sensitive data (for example, personal data), with tag-based policies that apply masking or access rules to everything carrying a tag. Nice-to-have
S9 A searchable catalog of tables and views with descriptions, owners and tags, and lineage showing which sources and jobs feed each table and which views, tables and shares depend on it. State whether lineage is captured at column level. Must-have
S10 A searchable audit history of logins, queries, data access and privilege changes, retained for at least [period] and exportable at any time. Must-have
S11 A data processing agreement, a current list of sub-processors, support for our privacy obligations (for example, GDPR), and a contractual time limit for notifying us of security incidents affecting our data. State the time. Must-have
S12 For any AI feature in the proposal: a written commitment that our data, prompts and results are not used to train models for other customers, and a list of the features that send data to a third-party model provider. Must-have

Implementation and support

ID Requirement Priority
M1 A phased migration plan from [current platform] covering schemas, data, SQL code, stored procedures, ELT jobs and BI connections, with named roles and the effort expected from both sides. State which code conversion is automated by tools and which is manual. Must-have
M2 A method for validating the migration, such as row counts, checksums and side-by-side comparison of query and report results, during a parallel run before cutover. Must-have
M3 Identification of who delivers the implementation (vendor, partner or both) and the relevant experience of the named team. Must-have
M4 A service-level agreement for availability, with service credits. State how availability is measured and whether it differs by edition or region. Must-have
M5 24×7 support for critical issues, with response-time targets by severity. State your targets. Must-have
M6 Advance notice of platform changes that affect SQL behavior, performance or cost, plus a public status page and root-cause reports for incidents that affect us. Must-have
M7 Training for data engineers, analysts and administrators, a named customer success contact, and periodic reviews of performance and cost. Nice-to-have

Commercial and pricing

ID Requirement Priority
C1 Your pricing model: consumption-based (per unit of compute time or data scanned), capacity-based (reserved or committed compute), or both. Show separately how compute, storage, data transfer, serverless background services and AI features are charged. Must-have
C2 A three-year cost estimate for the workload profile in Section 1, with every assumption stated (compute size, hours running, data scanned, storage growth), showing list price, discount and net price. Must-have
C3 The edition or tier needed to meet each Must-have requirement, and the price difference between editions. Must-have
C4 Terms for committed spend or capacity: the discount, what happens to unused commitment at the end of each term, and the rate charged for usage above the commitment. Must-have
C5 A cap on unit-price increases at renewal. State the cap. Must-have
C6 Proof-of-concept credits at no charge, with the vendor's engineering support. Nice-to-have
C7 Exit terms: export of all our data and metadata in open formats, the egress charges that would apply, and transition assistance at the end of the contract. Must-have

Questions to ask Data Warehouse vendors

These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.

  1. Which features in your proposal consume compute in the background (for example, automatic clustering, materialized view refresh, serverless ingestion, replication or AI functions)? Show us how we would see and cap that cost.
  2. Show us, live, how an administrator finds which team, user or query drove last month's spend, and what happens when a workload reaches its budget.
  3. Run a large ELT job and a BI dashboard refresh on the same data at the same time. How do you keep the dashboards responsive, and what does that isolation cost?
  4. Our peak is [number] concurrent dashboard users at [time of day]. Explain how your platform handles that peak, how quickly extra compute is added, and how it is billed.
  5. Which open table formats can you read and write today, and at which versions? Which features (row-level deletes, schema evolution, time travel, access policies) behave differently on open-format tables than on your native tables?
  6. How are row-level security and masking enforced when data is reached through a share, by another engine reading open-format tables, through a Python dataframe, or by an AI feature?
  7. Load a JSON source in which a new field appears and an existing field changes type. What happens to the load and to existing queries, and how does query performance compare with structured columns?
  8. Which constraints (primary key, foreign key, unique, not null) do you enforce, and which are informational only? How do you prevent duplicate rows in incremental loads?
  9. What is the typical delay between an event being published and it being queryable through your streaming ingestion, and what does streaming cost when it runs around the clock?
  10. For a migration from [current platform], which parts of the code conversion are automated and which are manual? How do you prove that results match, and what most often delays migrations like ours?
  11. If we leave, how do we export our data, SQL code and metadata, in which formats, and at what cost? Which features in your proposal would tie our code to your platform?
  12. Which AI features in your proposal are generally available, and which are in preview? Where do the models run, and is any of our data sent to a third-party model provider?
  13. Which features in your proposal require a higher edition, and which are on the roadmap? Give dates for the roadmap items.
  14. Describe your most significant service incident in the last two years that affected query availability or data: the cause, the customer impact and what changed afterwards.
  15. Provide a reference customer with a similar data volume and workload mix that migrated from a platform like ours.

Scoring rubric

Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.

Criterion Weight What a strong response shows
Core warehouse capability (SQL, semi-structured data, ingestion, ELT, sharing) 20% Every Must-have met in a generally available release and shown on your own data in the proof of concept.
Performance, concurrency and workload isolation 20% Representative queries and dashboards meet your targets at peak concurrency, with ELT and BI workloads isolated from each other.
Governance and security 15% Row, column and masking policies enforced everywhere the data can be reached, clear lineage and audit history, and the certifications you need.
Openness and portability 10% Read and write support for open table formats, standard SQL with few proprietary dependencies, and a clear, affordable path to export everything.
Integration with BI, data science and data tools 10% Supported connectors for your BI, ingestion and orchestration tools, usable Python access, and infrastructure-as-code support.
Cost transparency and total cost 15% A three-year estimate based on usage measured in the proof of concept, built-in budgets and cost attribution, a renewal cap and fair commitment terms.
Migration, implementation and support 10% A credible phased migration plan with automated code conversion where possible, validation before cutover, an experienced named team, and clear SLAs.
Total 100%

Scoring scale

  • 5 Exceeds: meets every Must-have and most Nice-to-haves, shown in a demo or proof of concept, with a matching reference customer.
  • 4 Strong: meets every Must-have and some Nice-to-haves, with clear evidence.
  • 3 Adequate: meets most Must-haves; gaps have a credible workaround or a dated roadmap commitment.
  • 2 Weak: misses one or more Must-haves, or the answer is vague.
  • 1 Poor: does not meet the requirement, or no answer.

Frequently asked questions

What should a data warehouse RFP include?

A profile of your workloads (data sources and volumes, how fresh the data must be, users and peak concurrency); requirements for SQL, ingestion, workload isolation, open table formats, data sharing and governance, each marked Must-have or Nice-to-have; integration, security and compliance requirements; migration and support terms; a pricing section that asks for consumption and committed options; and the rubric you'll score with. This template includes all of them.

What are the key requirements for a data warehouse?

Start with separation of storage and compute, elastic compute that suspends when idle, and isolation between workloads such as ELT and BI. Add ingestion (batch, change data capture and streaming), native handling of semi-structured data, governance (row- and column-level security, masking, lineage and audit), cost controls, and support for open table formats so your data stays portable. The requirements tables on this page list each one in a form you can paste into your RFP.

How do you compare data warehouse pricing between vendors?

Give every vendor the same workload profile and ask for a three-year estimate with its assumptions written out, because consumption-based and capacity-based prices can't be compared from list rates alone. Ask which background services consume compute, and what happens to unused commitments. Then rerun each estimate with the usage you measured in the proof of concept before you negotiate.

How long does a data warehouse RFP take?

The example schedule in this template runs about 14 weeks from kickoff to contract award, including three weeks for vendor responses and about four weeks for a proof of concept on your own data. Allow more time if you're migrating a large warehouse with many stored procedures, or if security review of a new cloud service is new to your organization.

Related RFP templates

Download Template

More information technology templates