Handling Slow Cascading Deletes In Rails

Nathan Kontny
Nathan Kontny January 04, 2020

Nate is a hands-on developer building products and running companies. His previous experience as the CEO of Highrise and CTO of Inkling helped him hone his skills as a software designer, engineer, founder, writer & vlogger.

Daddy Warbucks: You lock the orphans in the closet.
Miss Hannigan: They love it!


If you're using a development framework to interact with data (Rails, Django, Express, whatever), you've most likely had to make smart choices on how cascading deletes work in your system. And often in large systems, you're forced to make a compromise...

You could have your app and framework manage all those deletes keeping close control over validation and object lifecycles, which is ideal but often poor in performance for large records sets. Or, you could have your database handle the cascading deletes, but then you lose things like your lifecycle hooks.

So today, for Rails, we're releasing a small but useful utility that provides an alternative (and in some cases, better) way to do cascading deletes/destroys. It's called Miss Hannigan and you can find it here.

To quickly catch beginners up, Rails has some great tooling to deal with parent-child relationships using has_many:

class Parent < ApplicationRecord
    has_many :children

By default, what happens to children when you delete an instance of Parent? Nothing. Children just sit tight or in our more typical vernacular, they're orphaned.

To cleanup those orphaned records, you consider two Rails options we'll explain below: destroy the children, or delete the children. Both options present some problems.

dependent: :destroy

Destroying the children is ideal. You do that by setting dependent: :destroy on the has_many relationship. Like so:

class Parent ApplicationRecord
    has_many :children, dependent: :destroy

Rails, when attempting to destroy an instance of the Parent, will also iteratively go through each child of the parent calling destroy on the child. The benefit of this is that any callbacks and validation on those children are given their day in the sun. If you're using a foreign_key constraint between Parent -> Child, this path will also keep your DB happy. (The children are deleted first, then the parent, avoiding the DB complaining about a foreign key being invalid.)

But the main drawback is that destroying a ton of children can be time consuming, especially if those children have their own children (and those have more children, etc.). If you're on a hosting platform like Heroku, which caps your max request length at 30s, your deletes won't even work as they'll be rolled back following a timeout error.

So, many of us reach for the much faster option of using a :delete_all dependency.

dependent: :delete_all

Going this route, Rails will delete all children of a parent in a single SQL call without going through the Rails instantiations and callbacks.

class Parent ApplicationRecord
    has_many :children, dependent: :delete_all

However, :delete_all has plenty of problems because it doesn't go through the typical Rails destroy.

For example, you can't automatically do any post-destroy cleanup (e.g. 3rd party API calls) when those children are destroyed.

And you can't use this approach if you are using foreign key constraints in your DB:

Another catch is that if you have a Parent -> Child -> Grandchild relationship, and it uses dependent: :delete_all down the tree, destroying a Parent, will stop with deleting the Children. Grandchildren won't even get deleted/destroyed.

Here at Census this became a problem. We have quite a lot of children of parent objects. And children have children have children... We had users experiencing timeouts during deletions.

Well, we can't reach for dependent: :delete_all since we have a multiple layered hierarchy of objects that all need destroying. We also have foreign_key constraints we'd like to keep using.

So what do we do if neither of these approaches work for us?

We use an "orphan then later purge" approach. Which has some of the best of both :destroy and :delete_all worlds.

dependent has a nifty but less often mentioned option of :nullify.

class Parent < ApplicationRecord
    has_many :children, dependent: :nullify

Using :nullify will simply issue a single UPDATE statement setting children's parent_id to NULL. Which is super fast.

This sets up a bunch of orphaned children now that can easily be cleaned up in an asynchronous purge.

And now because we're destroying Children here, the normal callbacks are run also allowing Rails to cleanup and destroy GrandChildren.

Fast AND thorough.

So we wrapped that pattern together into a utility we're releasing to everyone today. We call it Miss Hannigan. (Destroyer of Orphans. Miss Hannigan sounded less Game of Thrones)

It's a small piece of kit, but it gives you a new ability with has_many relationships. You can now add a :nullify_then_purge dependency. Like so:

class Parent < ApplicationRecord
    has_many :children, dependent: :nullify_then_purge

This will do the nullify and asynchronous purge (using ActiveJob) for you out of the box.

Another nice benefit, is that we use batch destroys of the children lowering the memory size of destroying a lot of children (a feature that's been dead on the vine for Rails Core for awhile).


It's worth noting there are other strategies to cleanup data when parent objects are deleted. For example, you could allow your DB (if it supports it) to handle its own cascading deletes. With Rails you would do:

add_foreign_key "children", "parents", on_delete: :cascade

Using that on Postgres would have children automatically delete when a parent is deleted. But that removes itself from Rails-land where we have other cleanup hooks and tooling we'd like to keep running.

Another alternative would be to use a pattern like acts_as_paranoid to "soft delete" a parent record and later destroy it asynchronously.

We hope you find it handy. It's not a big project, so you could add this in yourselves, but this makes it just a tad slicker. Would love to hear if you get a chance to use it or how you'd improve it.

You can find Miss Hannigan here.

Related articles

Customer Stories
Built With Census Embedded: Labelbox Becomes Data Warehouse-Native
Built With Census Embedded: Labelbox Becomes Data Warehouse-Native

Every business’s best source of truth is in their cloud data warehouse. If you’re a SaaS provider, your customer’s best data is in their cloud data warehouse, too.

Best Practices
Keeping Data Private with the Composable CDP
Keeping Data Private with the Composable CDP

One of the benefits of composing your Customer Data Platform on your data warehouse is enforcing and maintaining strong controls over how, where, and to whom your data is exposed.

Product News
Sync data 100x faster on Snowflake with Census Live Syncs
Sync data 100x faster on Snowflake with Census Live Syncs

For years, working with high-quality data in real time was an elusive goal for data teams. Two hurdles blocked real-time data activation on Snowflake from becoming a reality: Lack of low-latency data flows and transformation pipelines The compute cost of running queries at high frequency in order to provide real-time insights Today, we’re solving both of those challenges by partnering with Snowflake to support our real-time Live Syncs, which can be 100 times faster and 100 times cheaper to operate than traditional Reverse ETL. You can create a Live Sync using any Snowflake table (including Dynamic Tables) as a source, and sync data to over 200 business tools within seconds. We’re proud to offer the fastest Reverse ETL platform on the planet, and the only one capable of real-time activation with Snowflake. 👉 Luke Ambrosetti discusses Live Sync architecture in-depth on Snowflake’s Medium blog here. Real-Time Composable CDP with Snowflake Developed alongside Snowflake’s product team, we’re excited to enable the fastest-ever data activation on Snowflake. Today marks a massive paradigm shift in how quickly companies can leverage their first-party data to stay ahead of their competition. In the past, businesses had to implement their real-time use cases outside their Data Cloud by building a separate fast path, through hosted custom infrastructure and event buses, or piles of if-this-then-that no-code hacks — all with painful limitations such as lack of scalability, data silos, and low adaptability. Census Live Syncs were born to tear down the latency barrier that previously prevented companies from centralizing these integrations with all of their others. Census Live Syncs and Snowflake now combine to offer real-time CDP capabilities without having to abandon the Data Cloud. This Composable CDP approach transforms the Data Cloud infrastructure that companies already have into an engine that drives business growth and revenue, delivering huge cost savings and data-driven decisions without complex engineering. Together we’re enabling marketing and business teams to interact with customers at the moment of intent, deliver the most personalized recommendations, and update AI models with the freshest insights. Doing the Math: 100x Faster and 100x Cheaper There are two primary ways to use Census Live Syncs — through Snowflake Dynamic Tables, or directly through Snowflake Streams. Near real time: Dynamic Tables have a target lag of minimum 1 minute (as of March 2024). Real time: Live Syncs can operate off a Snowflake Stream directly to achieve true real-time activation in single-digit seconds. Using a real-world example, one of our customers was looking for real-time activation to personalize in-app content immediately. They replaced their previous hourly process with Census Live Syncs, achieving an end-to-end latency of <1 minute. They observed that Live Syncs are 144 times cheaper and 150 times faster than their previous Reverse ETL process. It’s rare to offer customers multiple orders of magnitude of improvement as part of a product release, but we did the math. Continuous Syncs (traditional Reverse ETL) Census Live Syncs Improvement Cost 24 hours = 24 Snowflake credits. 24 * $2 * 30 = $1440/month ⅙ of a credit per day. ⅙ * $2 * 30 = $10/month 144x Speed Transformation hourly job + 15 minutes for ETL = 75 minutes on average 30 seconds on average 150x Cost The previous method of lowest latency Reverse ETL, called Continuous Syncs, required a Snowflake compute platform to be live 24/7 in order to continuously detect changes. This was expensive and also wasteful for datasets that don’t change often. Assuming that one Snowflake credit is on average $2, traditional Reverse ETL costs 24 credits * $2 * 30 days = $1440 per month. Using Snowflake’s Streams to detect changes offers a huge saving in credits to detect changes, just 1/6th of a single credit in equivalent cost, lowering the cost to $10 per month. Speed Real-time activation also requires ETL and transformation workflows to be low latency. In this example, our customer needed real-time activation of an event that occurs 10 times per day. First, we reduced their ETL processing time to 1 second with our HTTP Request source. On the activation side, Live Syncs activate data with subsecond latency. 1 second HTTP Live Sync + 1 minute Dynamic Table refresh + 1 second Census Snowflake Live Sync = 1 minute end-to-end latency. This process can be even faster when using Live Syncs with a Snowflake Stream. For this customer, using Census Live Syncs on Snowflake was 144x cheaper and 150x faster than their previous Reverse ETL process How Live Syncs work It’s easy to set up a real-time workflow with Snowflake as a source in three steps: