Identity Resolution Software: CDPs vs Direct Sync

Search for identity resolution software and you'll find two camps arguing about where the identity graph should live. Warehouse-native CDPs want it inside your Snowflake. Managed CDPs keep it in their own infrastructure. Both agree you need graph infrastructure, and both start at $50,000/year.

There's a third approach that neither camp mentions, for reasons that become obvious when you look at their pricing pages.

For teams whose customers already have a shared identifier across tools (an email address, a customer ID), direct-sync tools resolve identities by matching records on that key. No identity graph required. If you want the conceptual foundation, start with our identity resolution overview. This post compares the three approaches side by side so you can figure out which one fits.

What identity resolution software does and the two approaches to solving it

Identity resolution software links customer records across systems to build one profile per person. The mechanics vary by vendor, but the outcome is the same: when a customer exists in your CRM, billing tool, support platform, and email tool, each system should recognize them as the same individual.

The market has organized around two categories, both oriented toward enterprise buyers.

Warehouse-native tools run inside your data warehouse. You feed data from every source into Snowflake or BigQuery, and the software builds an identity graph as warehouse tables. You control the matching rules, configure survivorship logic (which email "wins" when a customer has three of them), and the resolved profiles stay in infrastructure you own. The advantage is full transparency. The tradeoff is that you need a warehouse, a data engineer to maintain match rules, and ongoing tuning of entity resolution logic.

The alternative is the managed-platform model. A CDP ingests your event data, handles resolution internally, and exposes unified profiles for downstream use. Setup is faster because you skip the warehouse. But the identity graph lives in the vendor's environment, which means debugging incorrect merges requires vendor support rather than a SQL query. Some use deterministic matching only. Others add probabilistic layers.

Both categories assume the same precondition: your identity problem is complex enough to require graph infrastructure. For a retailer with 10 million anonymous monthly visitors across devices, that assumption is correct. For a 50-person SaaS company where every customer signed up with an email, it probably isn't.

Enterprise identity resolution tools and what the infrastructure requires

The warehouse-native approach has become the dominant pitch among identity resolution providers over the past two years. The argument: your data warehouse is already the source of truth for analytics, so it should also house your identity graph. Run matching logic as SQL transformations, build the graph as warehouse tables, and you never hand your data to a third party.

I think this pitch makes sense for the right team. If you have a data warehouse, a data engineer, and genuine need for probabilistic matching, warehouse-native resolution gives you real control. You can build multiple graphs for different use cases (high-confidence deterministic for transactional email, high-reach probabilistic for ad targeting). You can configure survivorship rules. You can audit every merge decision because the graph lives in your SQL environment.

The cost, though:

• Warehouse compute: $500-$5,000/month depending on data volume

• CDP license with identity resolution: $50,000-$150,000+/year

• Data engineer to maintain the pipeline: $150,000+ annually

That's the warehouse-native side. Black-box CDPs streamline the infrastructure at the cost of visibility. You skip the warehouse and SQL-based graph management. The platform ingests event data, resolves identities internally, and outputs unified profiles you route to marketing tools. For teams that want resolution without managing warehouse infrastructure, this tradeoff can work. The concern is that probabilistic matching produces false merges regularly, and when it does, you're dependent on vendor support to investigate.

I don't have strong opinions on the warehouse-native vs black-box debate, honestly. Both solve the same matching problem with similar accuracy. What they share matters more than what distinguishes them: both assume you need an identity graph, both require significant investment, and both are built for use cases where records genuinely lack a shared identifier. Most identity resolution companies in both camps are selling to the same enterprise buyer profile.

Direct-sync identity resolution software: matching records without an identity graph

There is a gap in every identity resolution tools comparison I've read. The framing goes: warehouse-native is transparent, black-box is convenient, now pick one. The assumption baked in is that your identity problem requires graph infrastructure at all. For teams with identified customers, it doesn't.

Consider what identity resolution actually accomplishes at the end of the pipeline: every tool agrees on who the customer is and has current data about them. If your customers signed up with an email address, and that email exists in your CRM, billing tool, and support platform, the graph is solving a problem you don't have. Your records already share a key. The bottleneck is that your tools don't exchange data.

Direct-sync identity resolution software connects tools and matches records on the shared key during every sync cycle. Stripe customer with alex@company.com matches the HubSpot contact with the same email. When the Stripe subscription status changes, the CRM reflects it on the next sync. When the support rep updates a company name, it flows back.

The limitations are real and worth stating clearly. This approach only handles deterministic matching on a shared key. Anonymous visitor stitching across devices? Not possible. Household-level deduplication across millions of records with misspelled names? That's a job for entity resolution tools with probabilistic models. If you're an e-commerce company with high anonymous traffic, the direct-sync category isn't built for your problem.

But for B2B SaaS teams under 200 people, those limitations rarely matter. Customers log in. They provide email addresses. The matching challenge is solved by data the tools already store.

Oneprofile fits this category. You connect tools (or your Postgres database), pick a matching key, map fields, and records sync on schedule. Field-level change tracking means billing updates don't overwrite CRM fields set by other teams. We built it because we kept seeing teams evaluate $50,000/year identity resolution vendors when their actual problem was that Stripe and HubSpot didn't share data. Free tier, published pricing, setup in minutes.

Identity resolution software compared: pricing, warehouse, and setup time

The pricing column is what stops most small teams from evaluating the first two categories seriously. If your annual software budget is $50,000 total, spending all of it on identity resolution doesn't leave room for the tools that actually touch your customers.

Setup time matters more than people give it credit for. In my experience, a warehouse-native implementation involves standing up data pipelines, writing SQL for match rules, configuring survivorship, testing merge accuracy, and tuning thresholds. That's 4-8 weeks for a team that's done it before, longer for a first attempt. Direct-sync setup is connect, map, sync. Most teams finish during a lunch break.

How to choose identity resolution software based on your team size

Skip the feature matrix for a minute. Two questions matter:

Do your records share a common identifier? Open 20 random customer records across your CRM, billing tool, and support platform. If 90% or more share the same email address, you have a matching key. You don't need probabilistic matching. You don't need an identity graph. A direct-sync tool handles this.

Do you track anonymous visitors across devices? If you're a consumer e-commerce company with millions of anonymous sessions, and linking pre-login browsing to post-login accounts is a business requirement, you need probabilistic matching. That means a warehouse-native or managed CDP.

For most B2B SaaS teams, the first question answers the second. Your customers are identified. They gave you an email when they signed up. The identity resolution problem is a data connectivity problem.

If you're somewhere in between (some identified customers, some anonymous traffic, growing fast), the most common mistake is buying for the future instead of the present. Teams that start with enterprise identity resolution software because they might need probabilistic matching "eventually" spend six months implementing infrastructure for a problem they don't have yet. Start with what your data demands today.