Skip to main content
New tool CRON Expression Builder — preview next run times before you schedule Apex. Open the builder →
Diagram comparing DataRaptor Turbo Extract performance metrics against standard DataRaptor Extract speeds
Admin

DataRaptor Turbo Extract vs Extract - Key Differences

The choice between DataRaptor Turbo Extract and the standard version shows up directly in your page load times. Here is when to take the speed and when you actually need the flexibility of a classic extract.

The short answer

DataRaptor Turbo Extract pulls raw data from a single object and its immediate parents into a flat JSON structure with lower latency. Classic DataRaptor Extract is the one that handles custom JSON mappings, formulas, data masking, and complex multi-object queries.

Key takeaways Use DataRaptor Turbo Extract for simple read operations to keep server resource use down and page loads fast. Reach for the classic DataRaptor Extract when you need formulas on the values, data masking, or nested JSON schemas. Build with a Turbo Extract first and move to a classic Extract only if the mapping or transformation demands it. Keep Turbo Extract on a single object and its immediate parent lookups, and leave deeper relationship traversals to a classic Extract or an Integration Procedure.

If you've spent any time in OmniStudio, you've probably wondered when to reach for a DataRaptor Turbo Extract instead of the standard Extract. It's one of those choices that seems small at first, but it can actually make or break the performance of your FlexCards or OmniScripts. I've seen plenty of teams struggle with slow page loads simply because they used the wrong tool for a basic data pull.

Why DataRaptor Turbo Extract is usually the better choice

DataRaptor Turbo Extract is built to be fast. It skips the heavy lifting the classic Extract does, like complex mapping and formulas. It goes straight to the Salesforce database, grabs the fields you asked for, and hands them back in a flat JSON structure.

In my experience, if you're just trying to populate a simple list of records, Turbo is the way to go. It uses fewer server resources and has lower latency. When you're managing large data volumes, those milliseconds add up quickly. If you can use Turbo, you should.

Comparing DataRaptor Turbo Extract and the classic Extract

So what's the catch? The Turbo speed costs you flexibility. Think of it this way: Turbo is a motorcycle, fast but unable to carry much. The classic Extract is a moving truck. It takes longer to get there, but it can carry your whole house and rearrange the furniture on the way.

  • Mapping: Turbo gives you the data exactly as it looks in Salesforce. Classic lets you rename fields, nest them, and create a custom JSON structure.
  • Formulas: if you need math or string manipulation inside the DataRaptor, you need the classic version. Turbo doesn't support complex formulas.
  • Relationships: Turbo handles a single object and its immediate parents. If you need to pull from multiple unrelated objects or do complex joins, you'll hit a wall.
  • Performance: Turbo wins every time. It's optimized for high-traffic screens where you just need raw data quickly.

I always start with a Turbo Extract. If I find later that I need to transform the data or add a formula, I can switch to a classic Extract. Going the other direction is much harder once you've built out a complex mapping.

When to stick with the classic Extract

The classic DataRaptor Extract isn't obsolete. You need it whenever you have to shape the output for a specific integration or a complex UI component. If your JSON has to be deeply nested, or you're using Data Masks to hide sensitive info, Turbo won't get you there. And if you're following strict OmniScript naming conventions and need your output paths to match a specific schema, the mapping tab in the classic version is where you live.

Limitations of the Turbo method

One thing that trips people up is the relationship limit. DataRaptor Turbo Extract can pull from related objects (getting the Account Name from a Contact record, for instance), but it isn't designed for deep traversals. If you find yourself reaching four or five levels away, you're going to run into trouble. At that point you're better off with a classic Extract, or an Integration Procedure to stitch the data together.

Key takeaways

  • Use DataRaptor Turbo Extract for 90% of your simple read operations to keep performance high.
  • Choose the classic Extract only when you need formulas, complex JSON nesting, or data masking.
  • Turbo returns a flatter JSON structure, which is usually easier for FlexCards to handle anyway.
  • Always benchmark your load times. If a page feels sluggish, check your DataRaptors first.

Don't over-engineer your data layer if you don't have to. If you're just getting started with these tools, build the same simple query in both versions and compare the response times in the OmniStudio debugger. The gap shows up straight away.

Frequently asked questions

What is the difference between DataRaptor Turbo Extract and DataRaptor Extract?

DataRaptor Turbo Extract queries the database directly and returns raw fields in a flat JSON structure, with lower latency and higher performance. Classic DataRaptor Extract lets you rename fields, nest the output structure, apply formulas, and query across multiple unrelated objects.

When should you use DataRaptor Turbo Extract?

Use DataRaptor Turbo Extract for simple data retrieval, such as populating basic record lists in FlexCards or OmniScripts. It suits high-traffic screens where speed matters and the data needs no restructuring or formula transformation.

Does DataRaptor Turbo Extract support formulas?

No. DataRaptor Turbo Extract has no support for complex formulas, math, or string manipulation. If the data needs transforming in flight before output, use a classic DataRaptor Extract.

Can DataRaptor Turbo Extract query related objects?

DataRaptor Turbo Extract can pull fields from immediate parent objects, such as the Account Name on a Contact record. It cannot handle deep traversals across several relationship levels, and it cannot do complex joins across unrelated objects.

Newsletter

One email every Tuesday

New guides, tool updates, and the release-note changes that break things.

No spam. Unsubscribe in one click.

Comments

Loading comments...

Leave a Comment