Ruby’s Object#tap is a small but powerful method that often goes unnoticed. It allows you to “tap into” a method chain, perform some operation, and return the original object—regardless of what the block inside returns. This makes it particularly useful for debugging, configuration, or inserting side effects without breaking the flow of your code.

A Simple Use Case: Debugging

Take the following example:

1

n = [1,2,3].map { _1 % 2 }.map { _1 * 10 }

This returns [10, 0, 10]. But what if that’s not what you expected? You might want to inspect the result of the first map:

1
2
3
4

n = [1,2,3].map { _1 % 2 }
puts n.inspect
n = n.map { _1 * 10 }
puts n.inspect

Using tap, we can make this more elegant:

1
2
3
4

n = [1, 2, 3].map { _1 % 2 }
             .tap { puts _1.inspect }
             .map { _1 * 10 }
             .tap { puts _1.inspect }

What I am suggesting is a method of optimization not just for PostgreSQL but for other similar databases as well. This is a more primitive, hardware-level performance optimization where an exclusive partition or hard disk is dedicated just for the actual data. By doing so, all the read and write operations related to your data happen on that disk, while OS-level and software-level read/write operations happen on another disk. This approach also makes it easier to handle failure, monitor disk health, and isolate workloads effectively.

Why Store PostgreSQL Data in a Separate Partition?

Separating the data directory from the root filesystem has several advantages:

1. Improved Disk I/O Performance: Storing data on a dedicated partition ensures that database read/write operations are isolated from the OS and application processes, avoiding competition for disk I/O.
2. Efficient Disk Usage Management: By placing the data in a separate partition, you can allocate specific disk space for the database and prevent it from filling up the root partition.
3. Better Backup and Restore Control: Storing data in a dedicated location simplifies backup processes and makes restoring data more efficient.
4. Optimized Disk Types: Different types of storage media (e.g., SSD for faster reads/writes or HDD for archival data) can be used based on database needs.
5. Isolation for Security and Resilience: A dedicated partition reduces the risk of system failure in case of database corruption or storage issues.

I often see articles discussing Tailscale in multi-device setups, but I wanted to share my experience of using Tailscale primarily with a single machine. To clarify, it’s not technically a single device, but a combination of my work computer, phone, and a 10-inch Android tablet.

The Problem: Inefficient Remote Access

I work from home, and my computer serves as both my personal and work machine. There have been many times when I’ve needed to assist colleagues or push changes while away from my desk. In emergencies, I used to rely on AnyDesk to remote into my computer via my phone or tablet. While AnyDesk and similar tools like TeamViewer provide visual control over the desktop, they often suffer from lag, disconnections, and poor responsiveness on weaker connections, making simple tasks like opening a terminal or editing a file feel like a chore. The lag becomes especially pronounced when navigating large projects or deploying code, turning a few-minute task into a frustrating, time-consuming ordeal.

PostgreSQL is a mature, open-source relational database that has been widely adopted by many companies over the years. It has been my go-to database for most of my software career, helping me solve various performance challenges in my projects. Features like JSON generation, materialized views, and others have enabled me to scale APIs to handle millions of requests per second.

One effective strategy to improve the performance of web applications is to create a read-only replica of the primary database. This allows you to direct read-only queries (e.g., SELECT queries) to the replica, while write operations continue to target the primary database. Note that PostgreSQL doesn’t support multiple primary (or master) databases natively, but it does support multiple read replicas.

Although you can achieve distributed primary databases via schema or table sharding, that topic is beyond the scope of this article.

AWS ECS (Elastic Container Service) is a powerful Amazon Web Service that allows you to deploy Docker containers on various infrastructure options, including EC2 instances, Fargate (serverless containers), or even self-hosted servers. Being deeply integrated with AWS, ECS offers a cost-effective and seamless solution for managing containers in the Amazon ecosystem.

This guide assumes you are familiar with ECS and already have a task definition set up for your Rails application. Additionally, it assumes you know how to find your subnet ID and security group ID, as these will be required when running containers in your specific environment.