DEV Community: Yashika Vijayvargiya

When a String Assumption Broke Newsletter Tag Filtering in Ruby

Yashika Vijayvargiya — Fri, 14 Aug 2026 10:55:37 +0000

A bug doesn't always need hundreds of lines of code to cause a real production problem.

Sometimes, one assumption is enough.

In this case, the assumption was simple:

"Every tag is a String."

That assumption lived inside a Ruby filtering method in the open-source RubyEvents project.

It worked perfectly — until a tag wasn't a String.

That small mismatch was enough to turn a normal user interaction into an error.

This is the story of how I tracked it down and fixed it.

The Bug

The issue was reported as:

"Cannot Click tags on Newsletter"

The behavior was straightforward:

Open a newsletter.
Click one of its tags.
Instead of getting the filtered announcements, the application raises an error.

The issue was tracked as #1836.

At first glance, this sounds like a routing or controller problem.

It wasn't.

The failure was deeper in the tag-filtering logic.

Finding the Assumption

The filtering logic lived in Announcement::Collection#by_tag.

The original implementation looked like this:

def by_tag(tag)
  Collection.new(
    select { |a| a.tags.map(&:downcase).include?(tag.downcase) }
  )
end

The intent is easy to understand:

take all tags from an announcement
convert them to lowercase
compare them with the requested tag
return matching announcements

For normal String values, this works perfectly.

For example:

["Ruby", "Rails"].map(&:downcase)
# => ["ruby", "rails"]

But map(&:downcase) contains an important assumption:

Every element must respond to downcase.

That's not necessarily true.

Imagine the collection contains:

["Ruby", 123]

Calling:

["Ruby", 123].map(&:downcase)

tries to execute:

123.downcase

And integers don't have a downcase method.

The result is a NoMethodError.

So the real problem wasn't the newsletter link itself.

The newsletter was simply the path that exposed an unsafe assumption in the tag-filtering code.

The Interesting Part: Fixing the Bug Without Changing the Behavior

There were several ways this could have been "fixed."

For example, we could have assumed that all tags should always be Strings and modified the data at the source.

But that would change the scope of the fix.

The filtering method already had a clear responsibility:

Find announcements whose tags match the requested tag, case-insensitively.

The safer approach was to make that comparison resilient to the actual values it receives.

I changed the implementation to:

def by_tag(tag)
  Collection.new(
    select { |a| a.tags.any? { |tag_value| tag_value.to_s.casecmp?(tag) } }
  )
end

There are two important changes here.

1. `to_s` creates a safe comparison boundary

Instead of assuming:

tag_value.downcase

we explicitly convert the value:

tag_value.to_s

Now a String remains a String:

"Ruby".to_s
# => "Ruby"

And a non-String value becomes safely comparable:

123.to_s
# => "123"

The filtering code no longer crashes simply because a tag value isn't already a String.

2. `casecmp?` expresses the actual requirement

The original code lowercased both sides:

tag_value.downcase == tag.downcase

But the actual requirement isn't "convert everything to lowercase."

The requirement is:

Compare these values without considering case.

Ruby provides exactly that operation:

casecmp?

So the comparison becomes:

tag_value.to_s.casecmp?(tag)

This makes the intent clearer.

We're not transforming the data just to compare it.

We're performing a case-insensitive comparison.

Why `any?` Instead of `map`?

This is another small but meaningful improvement.

The old implementation transformed every tag:

a.tags.map(&:downcase).include?(tag.downcase)

The new implementation asks the question directly:

a.tags.any? { |tag_value| ... }

We don't actually need a transformed array.

We only need to know:

Does at least one tag match?

any? expresses that directly.

It also means we can stop looking as soon as a matching tag is found.

So the new implementation is not simply more defensive.

It is also closer to the intent of the operation.

Before vs After

Before

def by_tag(tag)
  Collection.new(
    select { |a| a.tags.map(&:downcase).include?(tag.downcase) }
  )
end

The hidden assumption:

Every tag
   ↓
must respond to #downcase

If one doesn't:

NoMethodError
   ↓
request fails
   ↓
user cannot follow the newsletter tag

After

def by_tag(tag)
  Collection.new(
    select { |a| a.tags.any? { |tag_value| tag_value.to_s.casecmp?(tag) } }
  )
end

Now the comparison becomes:

Tag value
   ↓
convert safely to String
   ↓
case-insensitive comparison
   ↓
match / no match

The existing filtering behavior remains intact while the unsafe type assumption is removed.

Why This Bug Is Easy to Miss

This is what I found most interesting about the issue.

The original code isn't obviously bad.

For a dataset containing only Strings, it is perfectly reasonable Ruby code:

a.tags.map(&:downcase)

The problem only appears when the runtime data doesn't match the assumption made by the implementation.

That's a common class of production bugs:

Code assumption
       ↓
"this value will always be a String"
       ↓
Works for normal data
       ↓
Unexpected value enters the system
       ↓
Runtime failure

The lesson isn't "never use downcase."

The lesson is:

Know where your assumptions about data types are coming from.

If a method operates on data that can contain different types, the boundary where those values are consumed should be resilient.

The Final Change

The actual production change was intentionally small:

- Collection.new(select { |a| a.tags.map(&:downcase).include?(tag.downcase) })
+ Collection.new(select { |a| a.tags.any? { |tag_value| tag_value.to_s.casecmp?(tag) } })

One line changed.

But that one line removed the assumption that every tag value is already a String.

I also fixed a linting issue in a follow-up commit.

The pull request was reviewed by the RubyEvents maintainer, passed all six checks, and was merged into the project's main branch.

PR: #1847 — Fix tag filtering for non-string tags

Issue: #1836 — Cannot Click tags on Newsletter

What I Learned

1. Small bugs can expose bigger assumptions

The code wasn't complicated.

The assumption behind the code was the real problem.

Whenever I see code such as:

items.map(&:some_method)

I now ask myself:

Do I know for certain that every item responds to this method?

That question becomes particularly important at boundaries where data may come from different sources.

2. Fix the behavior, not just the exception

It would have been easy to focus only on preventing the NoMethodError.

But the goal should be broader:

preserve existing behavior
make the comparison safe
make the intent clearer
avoid unnecessary transformations

The final implementation does all four.

3. Ruby's expressive methods can make intent clearer

Compare:

map(...).include?(...)

with:

any? { ... }

The second version tells the reader what we're actually asking.

We're not interested in producing another collection.

We're asking whether any tag matches.

That distinction matters when maintaining code long after the original bug has been forgotten.

Open Source Contributions Are Full of These Bugs

One of the things I enjoy about contributing to open source is that you get to work with code outside the assumptions of your own applications.

You don't know every historical decision behind a method.

You don't know every shape of data that has passed through it.

And you don't get to rewrite the whole system just because you found one imperfect assumption.

You have to understand the existing behavior, make the smallest responsible change, and prove that the fix doesn't break what was already working.

That's exactly what made this bug interesting to me.

The final diff was tiny.

The reasoning behind it was not.

The Takeaway

A production bug doesn't always announce itself with a complicated stack trace or a thousand-line fix.

Sometimes it's hidden inside a single assumption:

"Every tag is a String."

When that assumption stopped being true, clicking a newsletter tag stopped working.

The fix was to make the comparison type-safe, preserve case-insensitive matching, and express the filtering intent more directly.

One line changed. One user-facing failure removed. One more reminder that robust software is often about handling the values we didn't expect.

What Is Ponytail? A Beginner’s Guide to the AI Coding Companion Everyone Is Talking About

Yashika Vijayvargiya — Wed, 05 Aug 2026 09:29:26 +0000

⚠️ Note: AI developer tools evolve incredibly fast. Installation steps, supported editors, AI models, and configuration options may change over time. This article is not intended to be official documentation . Instead, its goal is to help you understand what Ponytail is, why it exists, and when you might want to use it . Before installing or configuring Ponytail, always refer to its official documentation for the latest instructions.

Introduction

If you’ve recently spent time on X (Twitter), Reddit, or developer communities, you’ve probably seen people talking about Ponytail.

Some developers call it an AI coding assistant.

Others think it’s an alternative to Cursor.

Some believe it’s a replacement for Claude Code.

And many assume it’s another Large Language Model (LLM) like ChatGPT or Claude.

None of these descriptions are entirely accurate.

This confusion exists because Ponytail is different from most AI tools developers are familiar with.

In this article, we’ll break down exactly what Ponytail is, what it is not, how it fits into the AI coding ecosystem, and when it makes sense to use it.

The Biggest Misconception About Ponytail

The first thing to understand is this:

Ponytail is not an AI model.

It cannot answer questions by itself.

It cannot generate code by itself.

It cannot replace ChatGPT, Claude, Gemini, or any other language model.

Instead, Ponytail works alongside an AI coding agent.

Think of it as a layer that influences how the AI approaches programming tasks.

Understanding the AI Coding Ecosystem

Many developers mix together editors, AI models, and coding agents.

These are different pieces of the puzzle.

Imagine you’re building a Rails application.

You have:

VS Code
    ↓
AI Coding Agent
    ↓
LLM (Claude / GPT / Gemini)

Each layer has a different responsibility.

VS Code

VS Code is simply your editor.

It doesn’t understand your code or generate anything on its own.

AI Model

Claude

GPT

Gemini

These are language models.

They understand natural language and generate code.

However, by themselves they don’t know how to edit files inside your project or interact with your development environment.

AI Coding Agent

An AI coding agent connects your editor to an AI model.

It can:

Read project files
Edit code
Create new files
Run commands
Analyze your repository
Suggest refactoring
Generate tests

Examples include various AI-powered coding assistants and editor integrations.

Ponytail

Ponytail sits on top of this workflow.

Instead of replacing your AI, it attempts to improve how the AI behaves while writing code.

An Analogy

Imagine you’re hiring a software engineer.

Without guidance, they might:

create unnecessary abstractions
introduce extra classes
over-engineer a simple solution
use complex design patterns for small problems

Now imagine giving that engineer a document that says:

Keep things simple.
Don’t create classes unless necessary.
Prefer existing libraries.
Avoid unnecessary complexity.
Write code another developer can understand quickly.

The engineer hasn’t changed.

Their instructions have.

Ponytail plays a similar role for AI coding assistants.

What Problem Does Ponytail Solve?

As AI became better at writing code, developers noticed recurring issues.

The AI often:

creates more files than necessary
writes excessive boilerplate
introduces unnecessary abstractions
overuses design patterns
invents helper classes
makes small tasks more complicated than they need to be

Sometimes this is useful.

Often it isn’t.

Ponytail aims to steer the AI toward simpler, more maintainable solutions.

What Ponytail Is NOT

Ponytail is not :

another version of ChatGPT
another LLM
a replacement for Claude
a replacement for Cursor
an IDE
a code editor
a compiler

Understanding this distinction removes most of the confusion.

Can Ponytail Work Without an AI?

No.

If you only install Ponytail, nothing happens.

You still need an AI coding agent backed by an AI model.

Think of it like this:

VS Code
❌

VS Code + Ponytail
❌

VS Code + AI Agent
✅

VS Code + AI Agent + Ponytail
✅

Does Ponytail Replace Cursor?

No.

Cursor is a complete AI-powered editor.

Ponytail is not.

Cursor provides:

editor integration
AI chat
autocomplete
repository understanding

Ponytail focuses on influencing how an AI coding assistant approaches problems rather than replacing the editor itself.

Does Ponytail Replace Claude?

No.

Claude is the intelligence.

Ponytail provides guidance.

Without Claude (or another supported model), Ponytail has nothing to reason with.

Does Ponytail Reduce Token Usage?

This is one of the most common questions.

The answer is:

Not directly.

Ponytail does not magically reduce the number of tokens consumed.

However, by encouraging the AI to produce smaller, simpler solutions with fewer unnecessary edits, some workflows may naturally involve fewer generated tokens.

This depends on:

the AI model
the coding task
the prompts
the agent’s behavior

So any reduction is a side effect of simpler outputs, not a guaranteed feature.

Is Ponytail Free?

Ponytail itself has generally been made available as an open-source project.

However, remember:

Using Ponytail does not eliminate the need for an AI model.

If your coding assistant relies on a paid AI service or API, those costs still apply.

Think of Ponytail as improving the workflow rather than replacing the underlying AI.

When Should You Use Ponytail?

Ponytail can be valuable when:

working on large production codebases
contributing to open-source projects
maintaining mature Rails applications
reviewing AI-generated code
encouraging simpler implementations
reducing unnecessary abstractions

These are situations where readability and maintainability often matter more than generating the maximum amount of code.

When Should You Avoid It?

Ponytail may not add much value if you’re:

learning programming from scratch
writing small throwaway scripts
experimenting with new ideas
using AI only for quick code snippets

In these cases, a standard AI assistant may already be sufficient.

A Rails Example

Suppose you ask your AI:

“Optimize this ActiveRecord query.”

Without guidance, the AI might introduce several service objects, helper modules, and layers of abstraction.

With a “keep it simple” philosophy, the AI is more likely to suggest:

adding the correct index
using includes
avoiding N+1 queries
simplifying the ActiveRecord chain
making a small, focused improvement

This often aligns well with how experienced Rails developers prefer to evolve applications.

Frequently Asked Questions

Is Ponytail another AI?

No.

Can Ponytail write code?

Not by itself.

Does Ponytail work without Claude or another AI model?

No.

Does Ponytail replace Cursor?

No.

Does Ponytail replace VS Code?

No.

Is Ponytail a code editor?

No.

Does Ponytail guarantee better code?

No. It provides guidance, but you should always review AI-generated code before merging it into production.

Final Thoughts

AI-assisted development is evolving at an incredible pace. New models, editors, and coding agents appear regularly, and the surrounding ecosystem changes just as quickly.

Ponytail is best thought of as a way to influence how an AI coding assistant approaches software development , encouraging simpler, more maintainable solutions rather than acting as a new AI model or editor.

Whether Ponytail becomes part of your daily workflow depends on your projects, your preferred tools, and how much you value AI-generated code that favors clarity over complexity.

As with any AI tool, the most important skill isn’t learning a specific product — it’s understanding where that product fits into the broader development workflow.

If this article introduced you to Ponytail for the first time, take a few minutes to explore its latest documentation, experiment with it in a small project, and decide whether its philosophy aligns with the way you like to build software.

Part 3: Optimistic Locking in Rails – Preventing Lost Updates Without Blocking Users

Yashika Vijayvargiya — Fri, 31 Jul 2026 10:49:53 +0000

Introduction

In the previous article, we learned how Pessimistic Locking prevents concurrent modifications by locking database rows.

While this guarantees data consistency, it also means other users may have to wait until the lock is released.

But what if conflicts are rare?

Should we still lock every row?

Probably not.

This is where Optimistic Locking comes in.

Instead of preventing concurrent updates, Optimistic Locking allows multiple users to edit the same record and detects conflicts only when they try to save their changes.

It assumes that conflicts are unlikely, making it a great choice for many web applications.

What is Optimistic Locking?

Definition

Optimistic Locking is a concurrency control strategy that allows multiple transactions to read and modify the same record without acquiring database locks.

Before saving changes, Rails checks whether the record has been modified by another transaction.

If it has, Rails raises an exception instead of silently overwriting the newer data.

In simple words:

"I believe no one else will modify this record. But before saving, I'll verify that assumption."

Why Do We Need Optimistic Locking?

Imagine an admin panel.

Two administrators open the same product.

Current Product:

Title: iPhone 16
Price: ₹80,000

Admin A changes:

Price → ₹75,000

Admin B changes:

Title → iPhone 16 Pro

Without optimistic locking:

Admin A saves.

Database:

Title: iPhone 16
Price: ₹75,000

A few seconds later...

Admin B saves.

Database becomes:

Title: iPhone 16 Pro
Price: ₹80,000

Admin A's update is lost.

This is called a Lost Update.

How Rails Solves This

Rails provides built-in support for Optimistic Locking using a column named:

lock_version

Whenever a record is updated:

Rails increments lock_version
Rails verifies the previous version before updating
If the version has changed, Rails raises an exception

Enabling Optimistic Locking

Simply add a column:

class AddLockVersionToProducts < ActiveRecord::Migration[8.0]
  def change
    add_column :products,
               :lock_version,
               :integer,
               default: 0,
               null: false
  end
end

That's it.

Rails automatically enables optimistic locking.

No additional configuration is required.

Example

Current row:

Admin A loads:

lock_version = 0

Admin B also loads:

lock_version = 0

Admin A updates:

product.price = 75000
product.save!

Database:

Notice:

lock_version

became

Now Admin B tries:

product.title = "iPhone Pro"

product.save!

Rails generates SQL similar to:

UPDATE products SET title = 'iPhone Pro', lock_version = 2 WHERE id = 1 AND lock_version = 0;

But the database contains:

lock_version = 1

Therefore:

0 rows updated

Rails raises:

ActiveRecord::StaleObjectError

Timeline

Admin A

Read Product

Version = 0

↓

Edit

↓

Save

Version becomes 1

----------------------------

Admin B

Read Product

Version = 0

↓

Edit

↓

Try Save

↓

StaleObjectError

What Happens Internally?

Suppose current version:

lock_version = 3

Rails updates using:

UPDATE products
SET
price = 100,
lock_version = 4
WHERE
id = 1
AND lock_version = 3;

If another transaction already updated it:

lock_version = 4

The WHERE condition fails.

No row is updated.

Rails knows someone modified the record.

Handling the Exception

Typical implementation:

begin
  product.update!(product_params)

rescue ActiveRecord::StaleObjectError

  flash[:alert] =
    "This product was updated by another user. Please reload and try again."

  redirect_to edit_product_path(product)
end

Instead of silently overwriting data, the user is informed.

Real Production Example 1

CMS Article Editing

Two editors modify the same article.

Without optimistic locking:

One editor overwrites another's work.

With optimistic locking:

Second editor sees:

"This article has changed since you opened it."

Real Production Example 2

Admin Dashboard

Inventory manager changes:

Stock = 15

Manager B changes:

Price = ₹500

Instead of losing one update,

Rails detects the conflict.

Real Production Example 3

User Profile

Editing profile:

Name
Bio
Address

Conflicts are rare.

Blocking users would hurt UX.

Optimistic locking is a better fit.

Advantages

✅ No waiting

✅ Better scalability

✅ Better user experience

✅ No database locks

✅ Great for read-heavy applications

Disadvantages

❌ Save may fail

❌ Users must retry

❌ Not suitable for financial systems

❌ Doesn't prevent concurrent reads

Optimistic vs Pessimistic Locking

Understanding Database Locking in Ruby on Rails: Types, Examples, and Best Practices

Yashika Vijayvargiya — Wed, 15 Jul 2026 08:39:39 +0000

Goal of this article: Build a strong foundation before learning pessimistic locking, optimistic locking, deadlocks, and isolation levels.

When I started working with production Rails applications, I realized that most database problems were not caused by missing indexes but by concurrent requests modifying the same data. Understanding locking completely changed the way I design payment, inventory, and booking systems.

What is a lock?

A lock is a mechanism used by PostgreSQL to protect data from being modified incorrectly by multiple transactions at the same time.

In simple words:

A lock tells other transactions: “Someone is currently working with this data. Wait your turn.”

Imagine two people editing the same Google Doc at the same moment. Without coordination, one person’s changes could overwrite the other’s. Databases use locks to prevent similar problems.

Why do databases need locking?

Suppose an e-commerce application has only 1 item left in inventory.

Without locking, both requests may read:

Both transactions believe the product is available and both place an order.

Result:

This is called a race condition.

What is a race condition?

A race condition occurs when the final result depends on the timing of concurrent operations.

Example

If two requests execute this code simultaneously, both may read the same inventory value before either update occurs.

This is the fundamental problem locking is designed to solve.

Transactions: The Foundation of Locking

Locks exist inside database transactions.

A transaction guarantees that all operations inside the block either:

Succeed together (COMMIT)
Fail together (ROLLBACK)

Locks are typically acquired when the transaction begins modifying or explicitly locking rows.

How PostgreSQL Handles Concurrent Transactions

Consider two transactions.

PostgreSQL automatically prevents both transactions from modifying the same row simultaneously.

MVCC: Why SELECT Usually Doesn’t Block

One of PostgreSQL’s most important features is MVCC (Multi-Version Concurrency Control).

Instead of blocking readers, PostgreSQL creates multiple versions of rows.

Example

Transaction A updates a product but has not committed yet.

At the same time, Transaction B runs:

Transaction B usually does not wait. It reads the previous committed version of the row.

This is why PostgreSQL can handle many readers efficiently.

Common Concurrency Problems

1. Lost Update

Very common

Problem: Two users overwrite each other’s changes.

Correct result should be: $30

Actual result: $50

2. Dirty Read

Usually prevented in PostgreSQL

Reading data that another transaction has modified but not committed.

PostgreSQL’s default isolation level (Read Committed) prevents this.

3. Non-repeatable Read

Possible in Read Committed

You read the same row twice and get different values because another transaction committed between the reads.

4. Phantom Read

Isolation-level issue

A query returns a different set of rows the second time it runs because another transaction inserted matching records.

Rails Example: Preventing Double Booking

Unsafe code:

Safe code using locking:

What changed?

generates:

This acquires a row-level lock so only one transaction can modify that event record at a time.

Visual Timeline

Important Insight: PostgreSQL Uses Multiple Lock Types

Many beginners think there is only one lock.

In reality PostgreSQL has:

We’ll explore these deeply in later parts of the series.

How to See Locks in Production

PostgreSQL exposes lock information through pg_locks.

A more useful query:

This helps identify which transaction is holding a lock and which transaction is waiting.

Key Takeaways

Locks prevent race conditions and data corruption.

Locks exist inside transactions.

PostgreSQL uses MVCC so readers usually do not block writers.

Row locks protect individual records.

Table locks protect entire tables.

FOR UPDATE is the foundation of pessimistic locking in Rails.

Most production concurrency bugs are caused by missing transactions or missing locks.

Interview Question

Why does PostgreSQL allow many SELECT queries to run without blocking each other?

Answer: PostgreSQL uses MVCC (Multi-Version Concurrency Control). Instead of blocking readers, it keeps multiple versions of rows so a SELECT query can read the last committed version while another transaction is updating the row. This greatly improves concurrency and is one of PostgreSQL’s biggest advantages.

Next Article in the Series

Pessimistic Locking in Rails

We will dive into lock, with_lock, FOR UPDATE, NOWAIT, SKIP LOCKED, and real production examples such as inventory reservation and payment processing.

Originally published at https://railswithyashika.hashnode.dev on July 13, 2026.

PostgreSQL Index Types Explained with Real Rails Examples

Yashika Vijayvargiya — Thu, 02 Jul 2026 08:00:26 +0000

Part-1 Understanding Indexes before learning Index Types

Now that we understand what indexes are and why they matter, let’s explore the different types of indexes available in PostgreSQL and when to use them in Rails applications.

1. Single Column Index

The simplest and most commonly used index.

Query

User.find_by(email: "john@example.com")

Migration

add_index :users, :email

SQL Generated

CREATE INDEX index_users_on_email ON users(email);

When to Use

Email lookups
SKU lookups
UUID searches
Foreign keys

Real Example

Product.find_by(sku: params[:sku])

Without an index, PostgreSQL scans the entire table.

With an index, PostgreSQL can jump directly to the matching row.

2. Unique Index

A unique index improves lookup performance while also preventing duplicate values.

Migration

add_index :users, :email, unique: true

What It Solves

Prevents:

john@example.com
john@example.com

Common Use Cases

Email addresses
Usernames
External IDs
API tokens

Rails Validation vs Database Constraint

Many developers write:

validates :email, uniqueness: true

This is not enough.

Always add a database unique index because validations can be bypassed during race conditions.

3. Composite (Multi-column) Index

Used when queries filter using multiple columns.

Query

Order.where(user_id: 1, status: "paid")

Migration

add_index :orders, [:user_id, :status]

Important Rule

Index order matters.

[:user_id, :status]

Works efficiently for:

WHERE user_id = 1

WHERE user_id = 1
AND status = 'paid'

But not for:

WHERE status = 'paid'

Real Example

In e-commerce:

Order.where(user_id: current_user.id, status: "completed")

4. Partial Index

Indexes only a subset of rows.

Migration

add_index :users, :email, where: "active = true"

Example Query

User.where(active: true)

Why Use It?

Suppose:

10 million users
9 million inactive 
1 million active

Creating an index only for active users makes the index:

Smaller
Faster
Less memory intensive

Common Uses

Soft deletes
Active records
Published content
Pending jobs

5. Index with Order

Optimizes sorting operations.

Query

Product.order(created_at: :desc)

Migration

add_index :products, :created_at, order: { created_at: :desc }

Benefits

Useful for:

Product.order(created_at: :desc).limit(20)

Common in:

News feeds
Activity logs
Product listings

6. GIN Index

GIN stands for Generalized Inverted Index.

Used for:

JSONB
Arrays
Full-text search

JSONB Example

add_index :users, :preferences, using: :gin

Query

WHERE preferences @> '{"theme":"dark"}'

Real Rails Example

User.where("preferences @> ?", { theme: "dark" }.to_json)

Without GIN indexes, JSONB searches become slow as data grows.

7. Full Text Search Index

PostgreSQL can act as a search engine.

Migration

add_index :articles, "to_tsvector('english', content)", using: :gin, name: "index_articles_on_content_search"

Query

SELECT * FROM articles WHERE to_tsvector('english', content) @@ plainto_tsquery('rails indexing');

Useful For

Blogs
Documentation sites
Product search
Knowledge bases

8. Concurrent Index

One of the most important production techniques.

Problem

Running:

add_index :users, :email

on a huge table can lock writes.

Solution

class AddIndexToUsersEmail < ActiveRecord::Migration[8.0] 
  disable_ddl_transaction!
  def change 
    add_index :users, :email, algorithm: :concurrently 
  end 
end

Benefits

No downtime
No table lock
Safe for production

Real World

Never add indexes to large production tables without considering concurrent creation.

9. Expression Index

Indexes a calculated value instead of a column.

Query

User.where("LOWER(email) = ?", email.downcase)

Migration

add_index :users, "LOWER(email)", name: "index_users_on_lower_email"

Benefits

Supports fast:

Case-insensitive searches
Date transformations
String manipulations

10. Covering Index (INCLUDE)

Introduced to reduce table lookups.

Migration

add_index :orders, :user_id, include: [:status, :total]

Why Useful?

Query:

Order.select(:status, :total) .where(user_id: current_user.id)

PostgreSQL can answer directly from the index.

This is called an Index Only Scan.

Benefits

Fewer disk reads
Faster queries

11. BRIN Index

BRIN stands for Block Range Index.

Designed for huge tables.

Migration

add_index :events, :created_at, using: :brin

Best For

Logs
Analytics data
Audit records
Time-series events

Why?

Instead of storing every value, BRIN stores summaries for ranges of pages.

Result:

Extremely small indexes
Very low maintenance overhead

Example

100 million events

A BRIN index may be only a few MBs compared to hundreds of MBs for a B-tree index.

12. Hash Index

Optimized for equality lookups.

Migration

add_index :users, :email, using: :hash

Query

WHERE email = 'john@example.com'

Limitation

Does not support:

<
>
BETWEEN
ORDER BY

Because B-tree indexes support more operations, Hash indexes are rarely used.

Which Index Should You Choose?

Final Thoughts

Indexes are not about adding them everywhere.

A good database engineer first identifies:

Slow queries
Query patterns
Filter columns
Sort columns
Join columns

Then chooses the index that matches the workload.

Always verify improvements using:

EXPLAIN ANALYZE

and remember that every index speeds up reads but adds overhead to writes. The best indexing strategy is the one that balances both.

Concurrent Indexes: https://railswithyashika.hashnode.dev/postgresql-concurrent-indexes-in-rails-avoiding-downtime-in-production

Originally published at https://railswithyashika.hashnode.dev on July 1, 2026.

Understanding Indexes Before Learning Index Types

Yashika Vijayvargiya — Wed, 01 Jul 2026 07:59:39 +0000

Before diving into different types of indexes, let’s understand why indexes are needed.

Imagine a library with 100,000 books.

If someone asks for a book named “Clean Code”, there are two ways to find it:

Without an Index

You start from the first shelf and check every book one by one until you find the required book.

This approach is similar to a Sequential Scan in PostgreSQL.

SELECT * FROM books
WHERE title = 'Clean Code';

PostgreSQL may need to scan every row in the table to find matching records.

As the table grows from thousands to millions of rows, query performance degrades significantly.

With an Index

Now imagine the library has a catalog that stores:

Clean Code → Shelf A12
The Pragmatic Programmer → Shelf B03
Refactoring → Shelf C08

Instead of checking every book, you first look at the catalog and immediately jump to the correct shelf.

This catalog is similar to a database index.

An index stores selected column values in a structure that allows PostgreSQL to locate rows much faster than scanning the entire table.

Why Not Index Every Column?

A common beginner question is:

If indexes make queries faster, why not create indexes everywhere?

Indexes improve read performance, but they come with a cost.

Whenever data changes, PostgreSQL must update both:

The table data
Every related index

For example:

User.create!(email: "john@example.com")

If the users table has 10 indexes, PostgreSQL must update all 10 indexes during the insert operation.

This means:

More storage usage
Slower INSERT operations
Slower UPDATE operations
Slower DELETE operations

Because of this trade-off, indexes should be added only for queries that are frequently executed and benefit from faster lookups.

How PostgreSQL Uses an Index

Suppose we have:

add_index :users, :email

And run:

SELECT *
FROM users
WHERE email = 'john@example.com';

Without an index:

Seq Scan on users

With an index:

Index Scan using index_users_on_email

The database can jump directly to matching records instead of examining every row.

A Simple Rule

Create an index when a column is frequently used in:

WHERE clauses
JOIN conditions
ORDER BY clauses
GROUP BY clauses

Examples:

User.find_by(email: email)

Order.where(user_id: current_user.id)

Product.order(created_at: :desc)

Lead.where(status: "active")

These are strong candidates for indexing.

How to Verify an Index Is Being Used

Never assume PostgreSQL is using your index.

Use:

EXPLAIN ANALYZE
SELECT *
FROM users
WHERE email = 'john@example.com';

Look for:

Index Scan

instead of:

Seq Scan

This confirms PostgreSQL is benefiting from the index.

Understanding these fundamentals makes it much easier to choose the right indexing strategy, whether it is a simple B-Tree index, a composite index, a GIN index for JSONB data, or a BRIN index for massive datasets.

PostgreSQL Concurrent Indexes in Rails: Avoiding Downtime in Production

Yashika Vijayvargiya — Thu, 18 Jun 2026 07:02:08 +0000

When working with large production databases, adding an index may seem like a simple migration.

However, on tables with millions of records, a regular index creation can lock writes and impact your application's availability.

In this article, we’ll explore what concurrent indexes are, why they matter, and how to safely create them in Ruby on Rails.

The Problem with Normal Index Creation

Suppose we have a large users table with millions of records.

A typical Rails migration might look like:

add_index :users, :email

Behind the scenes, PostgreSQL executes:

CREATE INDEX index_users_on_email ON users(email);

While PostgreSQL builds the index, it acquires locks on the table.

On large tables this can lead to:

Slower API responses
Blocked INSERT operations
Blocked UPDATE operations
Blocked DELETE operations
Potential downtime during deployment

For example:

users table = 50 million rows

Creating an index on such a table can take several minutes, and during that time write operations may be affected.

The Solution: Concurrent Indexes

PostgreSQL provides a safer alternative:

CREATE INDEX CONCURRENTLY

This allows PostgreSQL to build the index while minimizing disruption to ongoing database operations.

In Rails, this can be achieved using:

class AddIndexToUsersEmail < ActiveRecord::Migration[7.1] disable_ddl_transaction!
  def change
    add_index :users, :email, algorithm: :concurrently
  end 
end

How Concurrent Indexes Work

Normal Index Creation

Lock table
↓
Scan rows
↓
Build index
↓
Unlock table

Concurrent Index Creation

Scan table
↓
Build index in background
↓
Track ongoing changes
↓
Finalize index

The application continues to serve requests while the index is being created.

Why disable_ddl_transaction! Is Required

A common mistake is forgetting:

disable_ddl_transaction!

PostgreSQL does not allow:

CREATE INDEX CONCURRENTLY

inside a transaction.

Rails wraps migrations in a transaction by default, so we must disable it before creating concurrent indexes.

Without it, Rails raises an error during migration.

Complete Rails Example

class AddIndexToBookingsUserId < ActiveRecord::Migration[7.1] 
disable_ddl_transaction!

  def change

    add_index :bookings, :user_id, algorithm: :concurrently

  end

end

When Should You Use Concurrent Indexes?

Concurrent indexes are recommended when:

The table contains millions of rows
The application is live
Downtime is unacceptable
The database receives frequent writes

Typical examples include:

Users table
Orders table
Bookings table
Transactions table

When Is a Regular Index Fine?

For smaller tables and development environments:

add_index :users, :email

is usually sufficient.

Since concurrent index creation performs additional work, it is generally slower than normal index creation.

Real Production Scenario

Imagine a booking platform with:

bookings table = 100 million rows

A slow query is identified:

Booking.where(hotel_id: params[:hotel_id])

The obvious fix is:

add_index :bookings, :hotel_id

Running a normal index creation during business hours could affect booking APIs.

Instead, deploying:

add_index :bookings, :hotel_id, algorithm: :concurrently

allows the application to remain available while the index is built.

Checking Existing Indexes

To view indexes in PostgreSQL:

SELECT * FROM pg_indexes WHERE tablename = 'users';

You can also use:

\d users

from the PostgreSQL console.

Interview Question:

Why do we use concurrent indexes in Rails?

A good answer is:

Normal index creation can lock writes on large tables and impact application availability. PostgreSQL provides CREATE INDEX CONCURRENTLY to build indexes with minimal locking. In Rails, this is achieved using algorithm: :concurrently along with disable_ddl_transaction!. Although concurrent indexes take longer to build, they are much safer for production systems with large datasets and high traffic

Conclusion

Creating indexes is one of the easiest ways to improve query performance, but doing it incorrectly in production can introduce downtime.

Whenever you’re adding indexes to large, high-traffic tables, consider using concurrent indexes. The migration may take longer to complete, but your users won’t experience disruptions while it runs.

A few extra minutes during deployment are often worth avoiding minutes of downtime in production.

Rails Performance Optimization: Fixing N+1 Queries with includes, preload, and eager_load

Yashika Vijayvargiya — Wed, 10 Jun 2026 10:22:00 +0000

Originally published on Hashnode:
https://railswithyashika.hashnode.dev/rails-performance-n-plus-one-queries

When working with associations in Rails, it's easy to accidentally introduce performance issues. One of the most common problems is the N+1 Query Problem.

In this article, we'll understand what N+1 queries are, how they impact performance, and the differences between includes, preload, and eager_load.

What is an N+1 Query?

Suppose we have the following models:

class User < ApplicationRecord
  has_many :posts
end

class Post < ApplicationRecord
  belongs_to :user
end

We fetch all posts:

@posts = Post.all

And display the author's name:

<% @posts.each do |post| %>
  <%= post.title %>
  <%= post.user.name %>
<% end %>

Queries Generated
Rails first loads all posts:

SELECT "posts".*
FROM "posts";

Then for each post:


- SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT
1; 
- SELECT "users".* FROM "users" WHERE "users"."id" = 2 LIMIT 1; 
- SELECT "users".* FROM "users" WHERE "users"."id" = 3 LIMIT 1;

If there are 100 posts, Rails executes:

1 query for posts
100 queries for users

Total: 101 queries

This is called the N+1 query problem.

Why is it a Problem?

As the amount of data grows:

Database load increases
Response times become slower
More memory and CPU are consumed
Application scalability decreases A page that works fine with 10 records can become painfully slow with 1,000 records.

Fixing N+1 Queries with includes

The simplest solution is:

@posts = Post.includes(:user)

Rails executes:

SELECT "posts".*
FROM "posts";

Then:

SELECT "users".*
FROM "users"
WHERE "users"."id" IN (1, 2, 3, 4, 5);

Only 2 queries are executed regardless of how many posts exist.

Understanding includes

Most Rails developers use includes, but many don't know how it actually works.

Example

Post.includes(:user)

Generated Queries

SELECT "posts".*
FROM "posts";

SELECT "users".*
FROM "users"
WHERE "users"."id" IN (1,2,3,4,5);

Rails loads records using separate queries and associates them in memory.

When Rails Converts includes into JOIN

Consider:

Post.includes(:user)
    .where(users: { active: true })

Now Rails generates:

SELECT
  posts.id,
  posts.title,
  users.id,
  users.name
FROM posts
LEFT OUTER JOIN users
ON users.id = posts.user_id
WHERE users.active = true;

Because the query references the users table, Rails automatically switches to a JOIN strategy.

Understanding preload

preload always loads associations using separate queries.

Example

Post.preload(:user)

Queries Generated

SELECT "posts".*
FROM "posts";

SELECT "users".*
FROM "users"
WHERE "users"."id" IN (1,2,3,4,5);

Notice that the generated SQL is similar to includes.
Key Difference
Unlike includes, preload never converts into a JOIN.
This will fail:

Post.preload(:user)
    .where(users: { active: true })

Error:

missing FROM-clause entry for table "users"

Since no JOIN is generated, Rails cannot reference columns from the users table.

When to Use preload

Use preload when:

You know separate queries are preferred.
You only want to avoid N+1 queries.
You don't need conditions on associated tables.

Understanding eager_load

eager_load always uses a LEFT OUTER JOIN.

Example

Post.eager_load(:user)

Query Generated

SELECT
  posts.id,
  posts.title,
  posts.user_id,
  users.id,
  users.name
FROM posts
LEFT OUTER JOIN users
ON users.id = posts.user_id;

Everything is fetched in a single query.

Filtering on Associated Tables

Post.eager_load(:user)
    .where(users: { active: true })

Generated SQL:

SELECT
  "posts".*,
  "users".*
FROM "posts"
LEFT OUTER JOIN "users"
ON "users"."id" = "posts"."user_id"
WHERE "users"."active" = TRUE;

This works because the users table is already joined.

includes vs preload vs eager_load

Method	Queries	Uses JOIN	Can Filter Associated Table
includes	Usually 2	Sometimes	Yes
preload	2	No	No
eager_load	1	Always	Yes

Which One Should You Use?

*Use includes
*
Post.includes(:user)

Default choice for most cases.

Use preload

Post.preload(:user)

When you explicitly want separate queries and no JOIN.

Use eager_load

Post.eager_load(:user)

When filtering, ordering, or searching on associated tables.

Detecting N+1 Queries

A few ways to identify N+1 problems:

Check Development Logs

Look for repeated queries being executed inside loops.

Use Bullet Gem

Add:

gem 'bullet'

Bullet will notify you whenever an N+1 query is detected.

Use Monitoring Tools

Scout APM
New Relic
Datadog

These tools help identify slow database queries in production.

Conclusion

N+1 queries are one of the most common performance issues in Rails applications.

Understanding the differences between includes, preload, and eager_load can help you write more efficient database queries and build scalable applications.

As a rule of thumb:

Start with includes
Use preload when you want guaranteed separate queries
Use eager_load when you need JOIN-based filtering

A few minutes spent analyzing your SQL queries can save hours of performance troubleshooting later.

DEV Community: Yashika Vijayvargiya

When a String Assumption Broke Newsletter Tag Filtering in Ruby

The Bug

Finding the Assumption

The Interesting Part: Fixing the Bug Without Changing the Behavior

1. to_s creates a safe comparison boundary

2. casecmp? expresses the actual requirement

Why any? Instead of map?

Before vs After

Before

After

Why This Bug Is Easy to Miss

The Final Change

What I Learned

1. Small bugs can expose bigger assumptions

2. Fix the behavior, not just the exception

3. Ruby's expressive methods can make intent clearer

Open Source Contributions Are Full of These Bugs

The Takeaway

What Is Ponytail? A Beginner’s Guide to the AI Coding Companion Everyone Is Talking About

Introduction

The Biggest Misconception About Ponytail

Understanding the AI Coding Ecosystem

VS Code

AI Model

AI Coding Agent

Ponytail

An Analogy

What Problem Does Ponytail Solve?

What Ponytail Is NOT

Can Ponytail Work Without an AI?

Does Ponytail Replace Cursor?

Does Ponytail Replace Claude?

Does Ponytail Reduce Token Usage?

Is Ponytail Free?

When Should You Use Ponytail?

When Should You Avoid It?

A Rails Example

Frequently Asked Questions

Is Ponytail another AI?

Can Ponytail write code?

Does Ponytail work without Claude or another AI model?

Does Ponytail replace Cursor?

Does Ponytail replace VS Code?

Is Ponytail a code editor?

Does Ponytail guarantee better code?

Final Thoughts

Part 3: Optimistic Locking in Rails – Preventing Lost Updates Without Blocking Users

Introduction

Why Do We Need Optimistic Locking?

Understanding Database Locking in Ruby on Rails: Types, Examples, and Best Practices

What is a lock?

Why do databases need locking?

What is a race condition?

Example

Transactions: The Foundation of Locking

How PostgreSQL Handles Concurrent Transactions

MVCC: Why SELECT Usually Doesn’t Block

Example

Common Concurrency Problems

1. Lost Update

2. Dirty Read

3. Non-repeatable Read

4. Phantom Read

Rails Example: Preventing Double Booking

Visual Timeline

Important Insight: PostgreSQL Uses Multiple Lock Types

How to See Locks in Production

Key Takeaways

Interview Question

Next Article in the Series

Pessimistic Locking in Rails

PostgreSQL Index Types Explained with Real Rails Examples

1. Single Column Index

Query

Migration

SQL Generated

When to Use

Real Example

2. Unique Index

1. `to_s` creates a safe comparison boundary

2. `casecmp?` expresses the actual requirement

Why `any?` Instead of `map`?