RETL vs SQL Traits

  • 2 April 2024
  • 8 replies
  • 266 views

Userlevel 1
Badge +1

Since RETL was released I am debating whether or not RETL is a replacement for SQL Traits. What you think?


8 replies

Badge

Admittedly, I haven’t set up RETL yet but this is my interpretation after reading through the docs back when it was released. I’m sure there are some added benefits of moving to RETL but I haven’t quite made the leap.

Going to follow this thread to see if there is more context from others who have established RETL.

Userlevel 1
Badge +1

Got it! Thanks for sharing Corey :) 

Hey Andrew - I’m on the Team at Segment that uses Segment, and we moved almost all of our SQL Traits to rETL in the last year. Reasons being: we were hitting the 100 column limit, rETL is generally more robust (less risk of someone changing something accidentally), and we also wanted to send some of these traits to destinations directly (along with using them in Engage for audiencing). It was a bit on a pain to move them initially, but we were also using the early beta version of rETL - it would be easier now.

Userlevel 1
Badge +1

SQL Traits is no longer for sale, so I believe it’s being superseded by RETL.

https://segment.com/docs/unify/Traits/sql-traits/

RETL is a much more flexible and robust feature than SQL Traits and I am working to migrate from SQL Traits to RETL.

Userlevel 1
Badge +1

We make a lot of use of the rETL functionalities. Not only to create traits on a person, but also to create track events. 

Badge

We still have some SQL traits performing their job quite well, but for all new traits, we are adopting rETL. In my opinion, SQL traits are easier to set up and use, but rETL offers more flexibility.

The more I use Reverse ETL the more I like it :)

I went through this exercise and converted all our SQL Traits to RETL and these were my findings:

  • Watch cost.  Our Snowflake compute credits doubled (we will definitely max out on RETL) at the initial shift.
  • Understand how many models and how many destinations for each model.  Each destination for the model will contribute to # of records for your RETL limit.  So you could run three models or one large model… it becomes a numbers game
  • Compute credits are gold as well.  Freeing up some SQL traits allowed us to add more computed traits
  • RETL traits sent in via Segment Profiles are custom traits.  Unless they were sent in via SQL, then they stay SQL traits.  Little quirk to remember when building audiences and journeys.

All in all, through testing and many iterations over a few weeks, I ended on a hybrid of SQL &  RETL.  Traits with long sync times or many changes with 1 destination, I moved back to SQL.  Queries with many destinations, that needed faster sync times, stayed in RETL.  Best of both worlds.

Reply