We use cookies. Privacy choices

    Skip to content

    Live webinar Nov 5: save your seat

    Fluree AI · Resolve

    Every table, one governed graph.

    Create golden records from your structured data. The same customer, product or supplier across warehouses, lakes and operational databases resolves to one record, with lineage to every source, queried where the data lives or built from a lake table into a verified twin that stays in sync.

    Book a demoHow mapping works
    Want the full hour? Unified Intelligence, the webinar replay
    01 Thesis

    The facts that run a company are already in tables: customers in the CRM, materials in the ERP, transactions in the warehouse. The trouble is that each system keeps its own copy of the world, under its own names, and none of them is the truth.

    The usual fix copies everything somewhere new and rebuilds the pipelines each time a schema changes. The copy drifts the moment it lands, and the meaning, which record is which customer, does not come with it.

    Fluree takes the other route. Tables become graph facts through a W3C mapping, queried where they live, or, for lake tables, built into a verified twin. The same record in three systems resolves to one golden record with lineage to every source, under your ontology and your policy, and source updates flow through the same pipeline. The result lives in FlureeDB, with the same identifiers, history and policy as every other fact.

    sourcesIceberg (Parquet)Postgres · SQL Server · OracleSnowflake · BigQuery · RedshiftCSV · extracts
    ResolveR2RML mapping, rows to factsqueried in place or as a twinclassified against your ontologyresolved to golden recordslake twins synced on a watermark
    the graphFlureeDB, same identifiershistory: Iceberg snapshots, twin time travelpolicy: enforced inside the scanagents · search · analysts
    Figure 1. A table is mapped with the W3C R2RML standard and queried where it lives; an Iceberg table can also be materialized into a verified native twin. Records are classified against your ontology and resolved to golden records, and every fact lands in FlureeDB with its lineage.
    02 Capabilities

    Ten things ETL and MDM can’t do.

    Side by side with MDM suites
    1. 01Query tables in placeIceberg tables and SQL sources are read on the fly through an R2RML mapping. Nothing is copied, no index is built.
    2. 02One query across systemsNative ledgers and mapped sources answer the same SPARQL or JSON-LD query, joined in one execution.
    3. 03Pushdown, not pull-everythingFilters, partition pruning and column pruning go to Iceberg. A whole graph block compiles to one SQL statement where its shape allows.
    4. 04Any warehouse, one endpointOne Trino or Starburst coordinator fronts Postgres, MySQL, SQL Server, Oracle, Snowflake, BigQuery, Redshift, Iceberg and Delta.
    5. 05A verified twin when you need onefluree materialize builds a native copy of an Iceberg source, checks it against the source, and drops it if the check fails.
    1. 06Sync on a watermarkTrack an Iceberg source and its twin refreshes on a timer, incrementally, resuming from its watermark after a restart.
    2. 07Classification against your ontologyTables, columns and records align to the concepts you govern in your ontology. Confident matches promote; ambiguous ones queue for review.
    3. 08One golden record per entityThe same customer in CRM, ERP and billing resolves to one record, with provenance to every source.
    4. 09Policy where the data isPolicies live in a model ledger and are enforced inside the scan. On a SQL source a hidden column is dropped before the statement is built; what a source cannot evaluate is denied, not opened.
    5. 10History you can queryIceberg snapshots by id or timestamp. A twin is a full ledger, with time travel and branching.
    03 In production

    Proven on messy data.

    Published deployments of the structured pipeline, each on records spread across several systems under different names. The numbers are from the published case studies.

    All case studies
    97.5%data accuracy across five product sourcesGlobal 500 consumer packaged goods company. Duplicates removed, a governed product ontology, the catalog live in three weeks.Case study 10+warehouses consolidated$2B+ pharmaceutical company. New analytics use cases live in three weeks instead of nine months; $3M in manual labor costs cut.Case study 330,000+customers unified into golden recordsCommunity bank, 113 branches, three to five reporting systems resolved into one governed record per customer.Case study
    04 Map

    Map. Query. Materialize.

    Graph sources docs
    Map
    A table becomes graph facts through a W3C R2RML mapping. The data stays where it is.
    Query
    One query spans mapped tables and native ledgers, and filters run at the source.
    Materialize
    A lake table can also become a verified native twin, kept current on a watermark.
    05 Deploy
    001

    In your FlureeDB

    The graph-source commands ship in the FlureeDB command line and server. Any cloud, any OS, air-gapped if it must be.

    002

    Next to your warehouse

    Iceberg on S3 or GCS is read directly. SQL sources go through a Trino or Starburst endpoint in your VPC, or the fluree-sql-bridge sidecar beside a single database, so Fluree holds no database connection.

    003

    In Fluree AI

    Classification, resolution and steward review run in Fluree AI, where the governed vocabulary also lives.

    Read the docsTalk to salesEntity resolution guide

    Put it on your tables.

    Bring one warehouse table and one CRM export. We map them, resolve them, and put the result in a graph you can query with the rest of your data.

    Book a working sessionRead the docs
    Flurio, the Fluree Yeti
    Trusted byU.S. Department of DefenseMorgan StanleyArizona State UniversityAssociated PressDow JonesCBC