Prophecy

Name: Prophecy
Brand: Prophecy

AI data prep and analysis: transform data into insights with AI pipelines.

Est 2017|Valuation $278M|Raised $116.2M

LinkedIn 33K|Web traffic 5K|FTEs 171|HQ Palo Alto, California, US

MarketsData Transformation Data Preparation

Published Oct 7, 2026

01Common complaints

1) SQL-only transformation teams standardized on dbt - If most work is warehouse SQL modeling and the organization is satisfied with dbt’s workflow and ecosystem, Prophecy may introduce additional cost and process overhead without clear benefit. 2) Organizations that need a connector-first ingestion platform - Prophecy is transformation-focused; products such as Fivetran specialize in broad connector coverage and ingestion. 3) Teams lacking Git/CI/CD operational maturity - Prophecy’s capabilities assume use of Git-based workflows, testing, and structured promotion. Teams not ready to adopt these practices may experience slow adoption. 4) Buyers requiring fully transparent enterprise pricing up front - Enterprise pricing is not fully public, which may complicate procurement if a fixed public price is required. 5) Strict compliance environments requiring publicly documented certifications beyond SOC 2 - SOC 2 is documented in vendor materials; ISO certifications and other privacy compliance attestations were not clearly documented in public sources. Buyers in strict compliance regimes should validate certifications with the vendor. 1) Documentation migration and fragmentation - Vendor documentation includes notices about migrating documentation, which may cause confusion for evaluators and indicates transition in documentation hosting. 2) Observability feature maturity - The product pages indicate that some observability and cost/performance features are in progress or described as forthcoming. 3) AI/privacy posture requires validation in each environment - Vendor materials describe the Copilot behavior and metadata usage; organizations should validate what metadata is shared, which LLM providers are used, and whether customer-managed keys or private networking are supported in their deployment model. 4) Release cadence and platform dependencies - The vendor maintains an active release cadence and introduces new integrations (for example, new auth methods and Databricks OAuth flows). While this indicates active development, it also requires change-management planning.

Deal disqualifiers (poor fit)

Very small teams already productive with dbt and notebooks.
Organizations focused primarily on ingestion/connectors rather than transformations.
Buyers requiring publicly documented ISO certifications or specific compliance attestations that were not available in public materials.

Why some customers might leave (inferred churn reasons)

Not directly documented in the retrieved review snippets. Likely churn drivers, inferred from category dynamics, include:

Moving to platform-native tooling to reduce the number of vendors.
Preference for code-first frameworks (dbt) for portability and governance simplicity.
Cost sensitivity as usage or user counts grow.

These inferences should be validated with customer interviews or reference checks.

02Why they buy

Differentiators supported by sources

Two-way visual ↔ code interoperability: vendor materials describe a synchronized visual canvas and code editor.
Generated native Spark/SQL output: vendor documentation highlights code artifact generation to facilitate code review and portability.
Packaging/plugins for reuse and standardization: the product describes reusable components for governance and standardization.
Integrated Git workflows and testing as part of the development lifecycle.

Where competitors may have advantages

dbt: larger community, ecosystem integrations, and a strong SQL-first model.
Matillion/Fivetran: broader connector ecosystems and ingestion-focused capabilities.

03Field reports

Review-platform signal (G2)

G2 lists Prophecy as very highly rated on G2; review volume is limited and some entries on directory sites appear to be unrelated to the data engineering product, suggesting possible listing collisions. Example G2 review snippet shown on the vendor page: > "I really like the niche and elegant ui… we can connect the dots between various sources and destination… It’s column lineage feature set it apart from other etl platform"

Capterra signal (name collision issue)

Capterra has a listing titled "Prophecy" that appears to refer to a forecasting/budgeting tool; this listing appears to be for a different product and not the Prophecy data engineering platform.

Community/social discussions (Reddit)

Older community threads include introductory discussion and mentions of converting legacy ETL workflows to Spark. Community signal is limited in the reviewed timeframe.

What customers say they like (themes)

Based on available review snippets and vendor/community material:

Visual UI that produces code, which appeals to mixed-skill teams.
Column-level lineage and governance features are highlighted in some reviews.
Logging and observability features are noted positively in a subset of reviewer comments.

Common criticisms and complaints (observed or inferred)

Accessible sources did not provide many direct low-star quotations specific to the vendor in the retrieved snippets. However, practical concerns evident from the research include: - Review ecosystem confusion (directory listing collisions), which complicates review validation. - Pricing opacity at the enterprise level (Enterprise = contact sales). - Platform scope: strong Databricks emphasis may be a limitation if an organization is Snowflake-only or non-Spark.

Why organizations report choosing Prophecy (as positioned)

Vendor and press materials indicate organizations adopt Prophecy to:

Reduce reliance on scarce Spark expertise by using low-code tooling.
Standardize pipelines with reusable components and introduce DevOps practices.
Enable collaboration across engineers and less-technical data users.

These are vendor- and press-reported reasons and should be validated through customer reference calls.

Public case studies with metrics

In the sources retrieved, no detailed customer case study pages with independently verified, quantified outcomes (for example, cycle-time reductions or cost savings) were found.

Vendor-published outcome claims (not independently verified)

Vendor materials include claims about large-scale operational ability (for example, reporting many production pipelines). These claims lack published methodology in the reviewed material (for example, definitions of what constitutes a pipeline or attribution across customers).

Vendor press materials also include growth claims that were not audited in the reviewed sources.

Implementation details and time-to-value

Vendor materials indicate the product can be tried via public SaaS by adding Databricks credentials and also supports on-prem or VPC installations, indicating a spectrum from rapid trials to more complex enterprise deployments.

Without independent customer case studies, actual time-to-value will likely vary depending on governance constraints, CI/CD maturity, and platform complexity.

04Best fit

Company size

Inferred fit from pricing and product positioning:

Mid-market to enterprise organizations.
Data teams with multiple engineers and analysts collaborating; product materials suggest multi-user plans aimed at collaborative teams.
Organizations that run or standardize on Databricks / Spark.

Industries

Likely stronger adoption where large-scale data transformation is central, including finance, healthcare, retail, media, and telecommunications. Industry references in press materials are descriptive rather than detailed case studies.

Roles/personas

Decision makers: VP Data/Analytics, Head of Data Engineering, Platform Engineering leadership.
Champions: Staff/principal data engineers, analytics engineering managers, data platform architects.
End users: data engineers and analytics engineers; some analyst personas may use low-code SQL features depending on deployment.

Qualification criteria (good fit)

Multiple pipelines requiring consistency, governance, and DevOps rigor.
Desire for visual collaboration while retaining Git, code review, and deployment discipline.
Databricks/Spark-centric environments where Spark-native optimizations are relevant.

05The pitch

What the product does (objective value proposition)

Prophecy is a low-code / "visual + code" data transformation and data engineering platform focused on building, deploying, and operating pipelines on modern cloud data platforms—including Databricks (Spark) and SQL warehouses. The primary proposition is that teams can develop pipelines visually while still producing native Spark/SQL code that can be versioned in Git and deployed via software engineering practices (testing, CI/CD). Prophecy includes AI (agents/copilot) features intended to assist in generating, fixing, and documenting pipelines. Vendor positioning materials describe: - A visual designer and code editor that remain synchronized (edits in either view are reflected in the other). - A stated reduction of vendor lock-in risk through generated Spark/SQL code artifacts. - Collaboration and standardization via reusable plugins/packages. - Integrated testing, Git workflows, and expanding observability capabilities.

Target market and market positioning

Prophecy primarily targets: - Data engineering teams building Spark pipelines (Databricks-centric in many product materials). - Analytics engineering and data teams seeking visual development while retaining code artifacts and software engineering practices. - Enterprises standardizing pipeline development across multiple users. Prophecy is positioned against (1) legacy ETL tools (migration/transpilation to Spark) and (2) elements of the modern data stack of point solutions, with vendor materials emphasizing a more unified transformation workflow. This positioning appears in press materials and product collateral. One press announcement described a major product release that positioned low-code SQL as enabling business data users to perform self-service transformations.

Get a comprehensive analysis of Prophecy including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →

Published Oct 7, 2026

01Common complaints

SQL-only transformation teams standardized on dbt

If most work is warehouse SQL modeling and the organization is satisfied with dbt’s workflow and ecosystem, Prophecy may introduce additional cost and process overhead without clear benefit.

Organizations that need a connector-first ingestion platform

Prophecy is transformation-focused; products such as Fivetran specialize in broad connector coverage and ingestion.

Teams lacking Git/CI/CD operational maturity

Prophecy’s capabilities assume use of Git-based workflows, testing, and structured promotion. Teams not ready to adopt these practices may experience slow adoption.

Buyers requiring fully transparent enterprise pricing up front

Enterprise pricing is not fully public, which may complicate procurement if a fixed public price is required.

Strict compliance environments requiring publicly documented certifications beyond SOC 2

SOC 2 is documented in vendor materials; ISO certifications and other privacy compliance attestations were not clearly documented in public sources. Buyers in strict compliance regimes should validate certifications with the vendor.

Documentation migration and fragmentation

Vendor documentation includes notices about migrating documentation, which may cause confusion for evaluators and indicates transition in documentation hosting.

Observability feature maturity

The product pages indicate that some observability and cost/performance features are in progress or described as forthcoming.

AI/privacy posture requires validation in each environment

Vendor materials describe the Copilot behavior and metadata usage; organizations should validate what metadata is shared, which LLM providers are used, and whether customer-managed keys or private networking are supported in their deployment model.

Release cadence and platform dependencies

The vendor maintains an active release cadence and introduces new integrations (for example, new auth methods and Databricks OAuth flows). While this indicates active development, it also requires change-management planning.

Deal disqualifiers (poor fit)

Very small teams already productive with dbt and notebooks.
Organizations focused primarily on ingestion/connectors rather than transformations.
Buyers requiring publicly documented ISO certifications or specific compliance attestations that were not available in public materials.

Why some customers might leave (inferred churn reasons)

Not directly documented in the retrieved review snippets. Likely churn drivers, inferred from category dynamics, include:

Moving to platform-native tooling to reduce the number of vendors.
Preference for code-first frameworks (dbt) for portability and governance simplicity.
Cost sensitivity as usage or user counts grow.

These inferences should be validated with customer interviews or reference checks.

02Why they buy

Differentiators supported by sources

Two-way visual ↔ code interoperability: vendor materials describe a synchronized visual canvas and code editor.
Generated native Spark/SQL output: vendor documentation highlights code artifact generation to facilitate code review and portability.
Packaging/plugins for reuse and standardization: the product describes reusable components for governance and standardization.
Integrated Git workflows and testing as part of the development lifecycle.

Where competitors may have advantages

dbt: larger community, ecosystem integrations, and a strong SQL-first model.
Matillion/Fivetran: broader connector ecosystems and ingestion-focused capabilities.

03Field reports

Review-platform signal (G2)

Example G2 review snippet shown on the vendor page:

"I really like the niche and elegant ui… we can connect the dots between various sources and destination… It’s column lineage feature set it apart from other etl platform"

Capterra signal (name collision issue)

Capterra has a listing titled "Prophecy" that appears to refer to a forecasting/budgeting tool; this listing appears to be for a different product and not the Prophecy data engineering platform.

Community/social discussions (Reddit)

Older community threads include introductory discussion and mentions of converting legacy ETL workflows to Spark. Community signal is limited in the reviewed timeframe.

What customers say they like (themes)

Based on available review snippets and vendor/community material:

Visual UI that produces code, which appeals to mixed-skill teams.
Column-level lineage and governance features are highlighted in some reviews.
Logging and observability features are noted positively in a subset of reviewer comments.

Common criticisms and complaints (observed or inferred)

Accessible sources did not provide many direct low-star quotations specific to the vendor in the retrieved snippets. However, practical concerns evident from the research include:

Review ecosystem confusion (directory listing collisions), which complicates review validation.
Pricing opacity at the enterprise level (Enterprise = contact sales).
Platform scope: strong Databricks emphasis may be a limitation if an organization is Snowflake-only or non-Spark.

Why organizations report choosing Prophecy (as positioned)

Vendor and press materials indicate organizations adopt Prophecy to:

Reduce reliance on scarce Spark expertise by using low-code tooling.
Standardize pipelines with reusable components and introduce DevOps practices.
Enable collaboration across engineers and less-technical data users.

These are vendor- and press-reported reasons and should be validated through customer reference calls.

Public case studies with metrics

In the sources retrieved, no detailed customer case study pages with independently verified, quantified outcomes (for example, cycle-time reductions or cost savings) were found.

Vendor-published outcome claims (not independently verified)

Vendor press materials also include growth claims that were not audited in the reviewed sources.

Implementation details and time-to-value

Without independent customer case studies, actual time-to-value will likely vary depending on governance constraints, CI/CD maturity, and platform complexity.

04Best fit

Company size

Inferred fit from pricing and product positioning:

Mid-market to enterprise organizations.
Data teams with multiple engineers and analysts collaborating; product materials suggest multi-user plans aimed at collaborative teams.
Organizations that run or standardize on Databricks / Spark.

Industries

Roles/personas

Decision makers: VP Data/Analytics, Head of Data Engineering, Platform Engineering leadership.
Champions: Staff/principal data engineers, analytics engineering managers, data platform architects.
End users: data engineers and analytics engineers; some analyst personas may use low-code SQL features depending on deployment.

Qualification criteria (good fit)

Multiple pipelines requiring consistency, governance, and DevOps rigor.
Desire for visual collaboration while retaining Git, code review, and deployment discipline.
Databricks/Spark-centric environments where Spark-native optimizations are relevant.

05The pitch

What the product does (objective value proposition)

Vendor positioning materials describe:

A visual designer and code editor that remain synchronized (edits in either view are reflected in the other).
A stated reduction of vendor lock-in risk through generated Spark/SQL code artifacts.
Collaboration and standardization via reusable plugins/packages.
Integrated testing, Git workflows, and expanding observability capabilities.

Target market and market positioning

Prophecy primarily targets:

Data engineering teams building Spark pipelines (Databricks-centric in many product materials).
Analytics engineering and data teams seeking visual development while retaining code artifacts and software engineering practices.
Enterprises standardizing pipeline development across multiple users.

Prophecy is positioned against (1) legacy ETL tools (migration/transpilation to Spark) and (2) elements of the modern data stack of point solutions, with vendor materials emphasizing a more unified transformation workflow. This positioning appears in press materials and product collateral.

One press announcement described a major product release that positioned low-code SQL as enabling business data users to perform self-service transformations.

Get a comprehensive analysis of Prophecy including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →

SQL-only transformation teams standardized on dbt

If most work is warehouse SQL modeling and the organization is satisfied with dbt’s workflow and ecosystem, Prophecy may introduce additional cost and process overhead without clear benefit.

Organizations that need a connector-first ingestion platform

Prophecy is transformation-focused; products such as Fivetran specialize in broad connector coverage and ingestion.

Teams lacking Git/CI/CD operational maturity

Prophecy’s capabilities assume use of Git-based workflows, testing, and structured promotion. Teams not ready to adopt these practices may experience slow adoption.

Buyers requiring fully transparent enterprise pricing up front

Enterprise pricing is not fully public, which may complicate procurement if a fixed public price is required.

Strict compliance environments requiring publicly documented certifications beyond SOC 2

SOC 2 is documented in vendor materials; ISO certifications and other privacy compliance attestations were not clearly documented in public sources. Buyers in strict compliance regimes should validate certifications with the vendor.

Documentation migration and fragmentation

Vendor documentation includes notices about migrating documentation, which may cause confusion for evaluators and indicates transition in documentation hosting.

Observability feature maturity

The product pages indicate that some observability and cost/performance features are in progress or described as forthcoming.

AI/privacy posture requires validation in each environment

Vendor materials describe the Copilot behavior and metadata usage; organizations should validate what metadata is shared, which LLM providers are used, and whether customer-managed keys or private networking are supported in their deployment model.

Release cadence and platform dependencies

The vendor maintains an active release cadence and introduces new integrations (for example, new auth methods and Databricks OAuth flows). While this indicates active development, it also requires change-management planning.