# active\_record Published articles for active\_record. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Rails Multi-Tenancy DevFeed: [Rails Multi-Tenancy]() Original publisher: [Read original article]() Author: Mike Dalessio, Kimberly Rhodes, Fernando Olivares Published: 2026-02-13T18:00:00Z Content type: article Language: en Sources: [37signals Dev]() Topics: [Multi-tenancy](), [Rails](), [SQLite](), [Databases](), [MySQL](), [Open Source](), [Replication]() Tags: [active-record](), [databases](), [demo](), [developer](), [multi-tenancy](), [mysql](), [open-source](), [rails](), [replication](), [sqlite]() ### AI overview Lead Programmer Mike Dalessio discusses multi-tenancy in Rails, including 37signals' work moving Fizzy toward separate customer databases, the Active Record Tenanted gem, safeguards against accidental data leaks, and challenges involving SQLite replication and failover. ### Source excerpt Lead Programmer Mike Dalessio shares the benefits of multi-tenant databases and how his work with Fizzy led to the the Active Record Tenanted gem. ## Partitioning a large table in PostgreSQL with Rails DevFeed: [Partitioning a large table in PostgreSQL with Rails]() Original publisher: [Read original article]() Published: 2025-04-28T00:00:00Z Content type: tutorial Language: en Sources: [Aha! Engineering Blog]() Topics: [PostgreSQL](), [Rails](), [Database](), [Amazon RDS](), [backups](), [Amazon S3](), [etl](), [Disaster Recovery](), [datadog]() Tags: [active-record](), [amazon-rds](), [amazon-s3](), [backups](), [datadog](), [disaster-recovery](), [etl](), [latency](), [migration](), [partitioning](), [performance](), [postgresql](), [rails]() ### AI overview This article explains how Aha! partitioned a very large PostgreSQL audit table used with Rails. It covers the migration strategy, operational and performance problems caused by billions of rows, and an archival process that moves audits older than 12 months to Amazon S3. ### Source excerpt Keeping a reliable history of changes is essential for our users. They need to know when a record was updated, who made the change, and why. They could be anxiously awaiting a notification about a dependency that is blocking their work. Maybe they w ## How Do You Know What ActiveRecord Table Has a user\_id Attribute? DevFeed: [How Do You Know What ActiveRecord Table Has a user\_id Attribute?]() Original publisher: [Read original article]() Author: Fuzzygroup Published: 2019-12-28T00:00:00Z Content type: tutorial Language: en Sources: [Scott Johnson]() Topics: [Development](), [data-modeling](), [business logic]() Tags: [active-record](), [activerecord](), [business-logic](), [class](), [classes](), [console](), [development](), [id](), [jumpstart](), [metaprogramming](), [migration](), [migrations](), [rails](), [relationships](), [schema](), [table]() ### AI overview This article explains how to identify application classes whose ActiveRecord-backed tables have a user_id attribute. It introduces a DataObject class with a .has_user_id method that can be run in the console, helping the author add belongs_to user relationships without repeatedly checking the schema. ### Source excerpt Even though I'm a firm, firm believer in agile, I've recently been experimenting with a throwback to waterfall style development and it very quickly left me with a fully featured data structure of tables and relationships modeled as example data. What I did is very rapidly write a series of migrations and then populate them to represent a sample "installation". My goal with this approach was to play to my strengths - data modeling - and avoid getting tied down in user interface stuff (my weakness). This was a very, very interesting approach and what I found was that I got much further along the lines of the "guts" of an application simply because I never got discouraged by: Oh Shite - I know this should look good but I'm too much of a hoser to make it look good; I guess I'll put it aside and go watch TV The downside to this is that I never bothered setting up the normal associations that you do when you write a migration; I simply thought about this application in terms of the example data: the users who would be using the system the data objects that they would create how the data objects would interact with each other One of the things that I noticed when I started filling in the basics like "belongs_to :user" was that I kept constantly jumping between the class I was working on and the schema file. Finally it hit me - what I needed was a method that I could execute in the console that would tell me what classes had a user_id attribute. And so I wrote a class called DataObject (for an ActiveRecord class which stores data) and a method .has_user_id. What I was looking for was output that looked like this: > DataObject.has_user_id Initiative Yes - has a user_id field KeyResultOwner Yes - has a user_id field KeyResult Yes - has a user_id field ObjectiveOwner Yes - has a user_id field ObjectiveType Objective Yes - has a user_id field OkrTeamMember Yes - has a user_id field OkrTeam Yes - has a user_id field OrganizationGroup Organization Quarter ResponsibilityRole Stat ## Stupid Simple ActiveRecord Optimizations or Why Rails Console is Essential for Development DevFeed: [Stupid Simple ActiveRecord Optimizations or Why Rails Console is Essential for Development]() Original publisher: [Read original article]() Author: Fuzzygroup Published: 2019-11-05T00:00:00Z Content type: tutorial Language: en Sources: [Scott Johnson]() Topics: [Rails](), [Optimization](), [Development](), [Database](), [Code]() Tags: [active-record](), [activerecord](), [code](), [console](), [database](), [development](), [optimization](), [rails]() ### AI overview The article explains how Rails console can reveal repeated database queries caused by repeated ActiveRecord association access. It demonstrates rewriting a method to store the associated goal in a local variable, reducing repeated reads and potentially improving both production and development performance without relying on server-side caching. ### Source excerpt Ever since 2008 when my pairing partner at the time, Jared, pushed me to basically live in the Rails console, I've been heavily, heavily dependent on the console as an essential developer tool. I just watched something that pointed out to me just why it is so damn important. Here's what I observed: 2.6.3 :057 > m.change_pct_today_over_goal? Goal Load (65.2ms) SELECT `goals`.* FROM `goals` WHERE `goals`.`habit_id` = 39 ORDER BY `goals`.`id` ASC LIMIT 1 Habit Load (0.4ms) SELECT `habits`.* FROM `habits` WHERE `habits`.`id` = 39 LIMIT 1 Goal Load (0.5ms) SELECT `goals`.* FROM `goals` WHERE `goals`.`habit_id` = 39 ORDER BY `goals`.`id` ASC LIMIT 1 Goal Load (30.2ms) SELECT `goals`.* FROM `goals` WHERE `goals`.`habit_id` = 39 ORDER BY `goals`.`id` ASC LIMIT 1 true I simply can't think that the fact that we're loading the goal from the database 3 times is an optimal use of computing resources. So I dug into the code and here's what I saw: # original def change_pct_today_over_goal? return false if self.goal.nil? return false if self.habit.goal.amount.nil? goal_amount = self.goal.amount.to_f actual_amount = self.amount amount_over_goal = actual_amount - goal_amount return false if amount_over_goal < 0 return false if amount_over_goal == 0 return true if (amount_over_goal / goal_amount).to_f * 100 >= 25.0 return false end The first 3 lines in the method above walk database associations back to the goal. The simple optimization is to store the goal in a local variable so it is only read once: # rewritten def change_pct_today_over_goal? goal = self.goal return false if goal.nil? return false if goal.amount.nil? goal_amount = goal.amount.to_f actual_amount = self.amount amount_over_goal = actual_amount - goal_amount return false if amount_over_goal < 0 return false if amount_over_goal == 0 return true if (amount_over_goal / goal_amount).to_f * 100 >= 25.0 return false end Now it is possible that with the right caching strategy server side, this change wouldn't be necessary but