How to Run an RFP for a Data Warehouse or Analytics Platform

1. Document your workloads before you write a single question

Vendors in this space sell very different architectures: separated storage and compute, dedicated clusters, lakehouse setups, and bundled BI layers. You cannot compare them fairly until you know what you need them to do.

Sit down with data engineering, analytics, and finance and capture:

• Data volume today and in 24 months: raw storage, compressed estimate, and growth rate.
• Ingestion pattern: batch nightly loads, micro-batches, or streaming. List the source systems (ERP, CRM, product database, event streams).
• Query profile: number of analysts and dashboards, concurrency at peak (for example, month-end close), and typical query complexity.
• Latency needs: which reports must refresh in minutes and which can run overnight.
• Existing tools: BI, orchestration, transformation, and identity provider the platform must work with.
• Constraints: data residency, industry regulations, and whether you need a specific cloud provider.

Turn this into a one-page workload summary. It becomes the appendix every vendor prices against, which is the single most useful thing you can do for pricing comparability.

2. Structure the RFP so answers are comparable

Keep the document focused. Long questionnaires get copy-pasted marketing answers. A workable structure:

1. Background and workload summary (from step 1).
2. Mandatory requirements: pass/fail items such as SSO/SAML, encryption at rest and in transit, role-based access control, audit logging, SOC 2 Type II or equivalent, and region availability.
3. Functional questions: ask how, not whether. "Describe how you handle concurrency spikes and what it costs" is better than "Do you support high concurrency?"
4. Pricing template: a spreadsheet you supply, not their rate card.
5. Implementation and support: onboarding plan, named contacts, support tiers, response times.
6. Commercial terms: request their standard order form and MSA up front, so legal review starts early.

Example question wording:

Using the workload summary in Appendix A, estimate monthly cost for months 1, 12, and 24. Show units consumed, unit price, and any assumptions about compute sizing, auto-suspend settings, or storage tiering.

Give vendors a firm deadline, typically two to three weeks, and a single point of contact for questions. Share all answers to vendor questions with every bidder.

3. Make vendors price your usage, not their rate card

Consumption pricing (credits, compute units, slots, or bytes scanned) is where most budget surprises come from. List prices tell you almost nothing until you know how many units your workload burns.

Your pricing template should require:

• Storage cost per TB per month, including any separate charge for time travel, backups, or fail-safe retention.
• Compute cost broken into unit price and estimated units for your workload.
• Data transfer and egress charges, especially cross-region and out to other clouds.
• Feature add-ons: governance, advanced security, or AI features often sit in a higher edition.
• Support tier cost, often priced as a percentage of spend.
• Discount structure at different annual commitment levels.

Ask each vendor to state their assumptions in writing. When the proof of concept runs (next step), you will compare those assumptions to measured consumption. Vendors who estimated low to win the deal show up clearly at this point.

4. Run a proof of concept on your own data

Shortlist two or three vendors for a proof of concept. Demos on vendor-curated datasets do not predict how your queries will perform or what they will cost.

Set the POC up like a test, not a sales exercise:

• Fixed duration: two to four weeks is a common range.
• Written success criteria agreed with each vendor before starting.
• Representative data: a real subset, masked if needed, at meaningful scale.
• Your queries: pick 10 to 20 real queries, including your slowest and most expensive ones, plus a peak concurrency simulation.
• Your team at the keyboard: vendor engineers can help, but your engineers should build the pipelines so you learn the actual effort involved.

Track for each vendor:

• Query runtime at normal and peak load
• Units consumed per query and per day
• Engineering hours to load data and build a basic pipeline
• Support responsiveness during the POC

Clarify in writing whether POC usage is free and who owns anything built during it.

5. Score with a weighted rubric agreed in advance

Agree the scoring weights before proposals arrive. Setting weights after you have a favorite invites bias and makes the decision hard to defend to finance or audit.

An example weighting, to adjust for your priorities:

Build total cost of ownership over three years, not one. Include platform fees, egress, support, implementation services, and internal engineering time. A platform that is cheaper on paper but needs an extra engineer to run is not cheaper.

Have each evaluator score independently, then meet to reconcile. Record the reasoning behind the final scores.

6. Negotiate the contract terms that protect you

Data platforms are sticky. Once pipelines and dashboards are built, switching is expensive, so your leverage is highest before signature. Focus on these terms:

• Commitment size: commit to what the POC supports, not the vendor's growth projection. You can expand later.
• Rollover of unused credits: ask that unused prepaid capacity carries into the next term if you renew.
• Renewal price protection: cap increases on renewal.
• Overage rate: overages should bill at your discounted rate, not list.
• Data portability and exit: the right to export all data in open formats at no extra charge, with an agreed transition period after termination.
• SLA and credits: uptime commitment, how it is measured, and the credit schedule.
• Price change notice: advance written notice before unit prices or edition packaging change.

Example clause language:

Upon renewal, Customer may apply any unused prepaid capacity from the prior term to the renewal term, provided the renewal commitment is equal to or greater than the prior term's commitment.

Fees for any renewal term shall not increase by more than [X]% over the fees for the immediately preceding term.

Finally, set up spend monitoring from day one: budget alerts, auto-suspend defaults, and a monthly review of consumption against the committed amount. Contract terms only help if someone watches the usage.

Let pingpong run it for you

pingpong drafts the RFP, finds and invites vendors, collects proposals through a private portal, scores them with five AI models and flags the gotchas above. It drafts every negotiation message for your approval, then keeps watching the market so you renegotiate before renewal. $100 for the first month, then $799 a month.

Common questions

How long should a data warehouse RFP take?

Many teams run the full process in roughly two to four months: a few weeks for requirements, two to three weeks for vendor responses, two to four weeks for the POC, and time for negotiation and legal review. Starting legal review of the vendor's MSA early is the easiest way to avoid delays at the end.

Should we sign a large annual commitment to get a bigger discount?

Only if your POC data supports that level of usage. Overcommitting is a common and expensive mistake, because unused credits often expire. Commit to a conservative figure, negotiate rollover rights, and agree in writing that expansions during the term receive the same discount rate.

How many vendors should we invite to the RFP?

Inviting four to six vendors to the written RFP and shortlisting two or three for a proof of concept is a common approach. More than that stretches your team's evaluation time, and a POC run properly takes real engineering effort per vendor.