The Vibe Coding Philosophy

Writing a database extension used to feel like performing open-heart surgery with a butter knife. One slip in C memory management and the entire cluster crashes. Vibe Coding is a mindset shift enabled by Rust and pgrx: moving from “don’t break it” to “build it as fast as you can think it.”

• Fearless Exploration: Rust’s compiler handles the safety, so you can focus on the algorithms.
• Instant Gratification: cargo pgrx run compiles and launches a live Postgres instance in seconds.
• Deep Integration: Access low-level Postgres hooks without the boilerplate of C macros.

PostgreSQL Storage Internals

The 8KB Page

To understand why we need a new storage model, we must first look at how the standard Heap Access Method works. Postgres organizes data into 8KB pages.

The Buffer Manager Overhead

Every time you read a row, Postgres loads an entire 8KB page into the Buffer Manager. This is efficient for OLTP, but creates massive IO overhead for analytical time-series scans that only need a few columns from billions of rows.

The 1D Storage Trap

Standard B-Trees

Standard Postgres uses the Heap to store rows mostly unordered as they arrive. To find data, we use B-Trees. But a B-Tree is fundamentally one-dimensional.

The Composite Index Trap

When you create a composite index on (tenant_id, time), you are sorting your data by tenant first, then by time.

• WHERE tenant_id = 1 AND t > now() - interval '1h' — FAST.
• WHERE t > now() - interval '1h' — SLOW (Fragmented across all tenants).

The Scan Gap Animation

In traditional storage, data for a specific timeframe across multiple tenants is scattered. The database must scan many pages and filter out irrelevant rows. Spiral changes this geometry.

The Spiral Proposal

The Gravity of Large Datasets

In a growing system, data has Entropy. As you ingest billions of rows, the traditional Heap becomes a massive “Gravity Well.” Standard 8KB pages are too small to handle the weight of analytical scans.

The Spiral Metaphor: Cosmic Storage

Spiral reimagines storage as a Spiral. Fresh data arrives at high velocity in the center, and as it ages, it migrates to outer “Lanes” (rollups).

Spiral’s User Interface: Magic Comments

Instead of complex DDL, Spiral parses standard SQL comments to define your analytics pipeline.

CREATE TABLE asset_ticks (
    t timestamptz NOT NULL,
    symbol_id int REFERENCES symbols(id), -- Auto-detected Tenant
    price double precision, -- Spiral: ohlc, stats, sketch
    vol int                 -- Spiral: sum
); 

Mathematics of Locality: Z-Ordering

To solve the Composite Index Trap, we use Z-Ordering (The Morton Curve). It interleaves the bits of multiple coordinates to create a single value that preserves multidimensional locality.

Decoding the Z-Value Formula

• (x_i, y_i): Individual bits of your coordinates.
• (2^{2i+1}) and (2^{2i}): Masks that “zip” bits together.
• The Result: A single scalar that keeps conceptual neighbors physically close.

Z-Ordering Interactive Visualization

Hover over the grid to see how the Morton Curve visits every point, linearizing space while keeping blocks physically close.

Standard vs. Z-Order: The Frontend Scan

Select a range! Row-Major (Standard) is perfect for horizontal scans, but fails for Vertical or Cluster slices. Z-Order provides “Fair Locality” for any shape by grouping data into power-of-two blocks.

What is a Table Access Method (TAM)?

Postgres 12 decoupled storage from the executor via the TAM API.

• Implement callbacks for insert, scan, delete.
• Control physical byte layout on disk.

Interactive: Direct Seek vs Page Traversal

Observe how the Spiral TAM calculates the address and jumps directly to the data.

Rust Implementation: repr(C) Structs

Ensure binary storage is hardware-compatible using #[repr(C)].

#[derive(Debug, Clone, Copy)]
#[repr(C)]
pub struct SpiralingRow {
    pub t: i64,          // 8 bytes
    pub tenant_id: i32,  // 4 bytes
    pub value: f64,      // 8 bytes
    pub padding: [u8; 40], // Total 64 bytes
}

The Binary Packing Logic

spiral_pack_delta reads from an unlogged table and packs it into the binary file.

let offset = (t * BUNDLE_SIZE as i64) + (tenant_id * ROW_SIZE as i64);
let bytes: [u8; ROW_SIZE] = unsafe { std::mem::transmute(data) };
file.seek(SeekFrom::Start(offset as u64))?;
file.write_all(&bytes)?;

EXPLAIN ANALYZE: Before & After TAM

Notice how Buffers: shared hit disappears.

-- BEFORE: Standard Heap Scan
-> Parallel Seq Scan on ticks (actual time=428.215..428.215 rows=1000000)
   Buffers: shared hit=4218

-- AFTER: Spiral TAM Direct Seek
-> Custom Scan (Spiral Binary Map) (actual time=0.076..0.076 rows=1)
   Buffers: shared hit=2 (catalog only)
   Direct IO: 64 bytes read via seek()

Incremental View Maintenance (IVM)

In standard Postgres, REFRESH MATERIALIZED VIEW rebuilds everything. Spiral tracks “dirty buckets” in a transactional changelog.

The Streaming Hierarchy in Motion

Watch data points flow from raw insert to cascading rollups.

Mathematical Engine: Welford’s Algorithm

How do we “merge” a standard deviation? Spiral uses Welford’s Algorithm to store moments ((n, M_1, M_2, M_3, M_4)).

Parallel Aggregation Lifecycle

Follow a data point from SQL INSERT to final analytical projection.

Stress Test — The 1B Scalability

Achieved ingestion rates exceeding 1.9 Million rows per second.

Conclusion: The Future is Extensible

PostgreSQL is a platform for data structures.

• Rust is the Key: Memory safety makes internals accessible.
• Math is the Leverage: Smart algorithms beat brute-force hardware.

Presented at PGDay Blumenau 2026.

A Personal Journey into Database Internals

I should start with a confession: I am not a math expert, nor am I a core PostgreSQL developer. I am a curious engineer who loves to experiment. Spiral is the result of letting my creative side take the wheel—a research project born from a simple desire to understand how databases work at the bit-level and to see if I could implement some of my own “crazy” ideas.

Everything you see here is a prototype. It is an exploration of what becomes possible when we use Rust to extend the heart of the database. I’m sharing this as a research outcome, hoping to find other curious minds who might want to contribute or challenge these concepts.

Try It in Five Minutes

Spiral targets PostgreSQL 16–18. Install via Homebrew on macOS:

brew install postgresql@18
brew install --build-from-source ./Formula/spiral.rb

Or build from source with cargo-pgrx:

cargo install cargo-pgrx
cargo pgrx init
cargo pgrx run pg18   # drops into a psql session with spiral loaded

Add to postgresql.conf so the planner hook and background worker start at boot:

shared_preload_libraries = 'spiral'

Then try the short walkthrough:

cargo pgrx run pg18 < examples/short_walkthrough.sql

Or paste this into any psql session:

CREATE EXTENSION spiral;
SET spiral.kickoff_date = '2026-01-01';

CREATE TABLE ticks (
    t         timestamptz NOT NULL,
    symbol_id int         NOT NULL,
    price     double precision, -- Spiral: ohlcv
    vol       int               -- Spiral: sum
) WITH (spiral.frames = '1m,1h', spiral.tenant = 'symbol_id');

-- Insert some data — background worker auto-refreshes rollups
INSERT INTO ticks SELECT
    now() - (random() * interval '2 hours'),
    (random() * 10)::int,
    100 + random() * 50,
    (random() * 1000)::int
FROM generate_series(1, 100000);

-- Manually refresh (or just wait for the bgworker)
SELECT spiral_refresh('ticks');

-- Query the 1-minute rollup
SELECT t, symbol_id, price_ohlcv_h, price_ohlcv_l, vol
FROM ticks_1m ORDER BY t DESC LIMIT 10;

The source is at github.com/jonatas/spiral.

The “Spiral” Concept: A Metaphor for Data Flow

The central idea behind this project is to stop thinking of data as a flat, linear history. As datasets grow to billions of rows, the traditional model faces what I call Data Gravity—where the weight of the data makes every operation exponentially harder.

In my experiments, I started imagining storage as a Spiral.

In this model, fresh data arrives at high velocity in the center. As it “cools” and ages, it migrates to outer orbits where it’s aggregated into stable, dense structures.

Multi-Tenancy: The Lane System

In a multi-tenant environment, the “Data Gravity” problem is multiplied. If we store everyone’s data in the same linear file, noisy neighbors can drown out everyone else.

Spiral solves this by assigning each tenant their own Lane within the spiral. Imagine a cosmic highway where each tenant has their own orbital path. This preserves locality not just in time, but in tenant identity. You can explore this concept in depth at the Spiral Interactive Lab.

The Geometry of Packing: Massively Multi-Tenant Scale

To understand how Spiral achieves constant-time seeks across billions of rows, we have to look at the Packing Geometry. By using an Archimedean spiral, we can map a 1D sequence (time) into a 2D plane where distance from the center represents “age” and the rotation phase represents “tenant identity.”

In this advanced simulator, you can push the system to 100 concurrent tenants. Watch how the Temporal Resolution (Step) and Packing Density configs mirror the internal bundle_size and frame_seconds parameters.

The Engineering Problem: Entropy and Page Overhead

PostgreSQL organizes data into fixed-size 8KB Pages. For analytical queries on massive time-series data, this creates a significant “IO Tax.”

The B-Tree Trap in Multidimensional Queries

B-Trees are the workhorse of Postgres, but they are fundamentally one-dimensional. When you create a composite index on (tenant_id, time), you are prioritizing one dimension over the other.

• Query A (WHERE tenant_id = 1 AND t > ...): Fast.
• Query B (WHERE t > ... across multiple tenants): Slow.

How Spiral Differs from Existing Solutions

Several mature tools address time-series at scale. Spiral explores a different set of trade-offs.

The key architectural difference: you never change your query. TimescaleDB continuous aggregates are separate views that you must remember to query. Spiral intercepts the original query and routes it transparently — the application code never changes when a new rollup tier is added or a bucket becomes dirty.

Geometry-Aware Indexing with Z-Order

B-Trees excel at single-dimension queries, but fall apart when you filter on tenant_id and t together. Z-ordering maps both dimensions into one number so that rows close in both dimensions stay close in storage — turning expensive multi-column scans into tight range scans.

Try it: sort by Color, Size, or Z-Order, then run a query and watch how many pages load:

That is exactly what spiral_zorder does in SQL. It encodes both dimensions into a single number so that values close in both tenant and time land close together on the number line — enabling a single BETWEEN lo AND hi index scan to retrieve a 2D rectangle without touching unrelated rows.

-- Create a z-order index on the rollup view
CREATE INDEX ON sensor_data_1m USING btree (
    spiral_zorder(spiral(t), ARRAY['sensor_id'])
);

-- Spiral injects this automatically for tenant-scoped queries:
-- WHERE spiral_zorder(spiral(t), ARRAY['sensor_id']) BETWEEN <lo> AND <hi>

spiral_zorder uses FNV-1a hashing — stable and deterministic across restarts, so index values written today still match values computed at query time tomorrow.

Interactive Proof of Locality

Compare how Standard Row-Major and Z-Order Morton handle memory access. Select a range and watch the Page Loads metric.

Prototyping a Custom Table Access Method (TAM)

PostgreSQL 12 decoupled the internal storage from the executor through the Table Access Method (TAM) API. This is where the research got practical. Using Rust and pgrx, I implemented a prototype handler that bypasses the standard Heap.

// src/tam.rs — TAM registration
pub unsafe fn spiral_tam_handler(_fcinfo: pg_sys::FunctionCallInfo) -> pgrx::datum::Internal {
    let routine = PgMemoryContexts::TopMemoryContext.palloc_struct::<pg_sys::TableAmRoutine>();
    (*routine).type_ = pg_sys::NodeTag::T_TableAmRoutine;

    // Scan path — fully implemented
    (*routine).scan_begin       = Some(spiral_scan_begin);
    (*routine).scan_getnextslot = Some(spiral_scan_getnextslot);
    (*routine).scan_end         = Some(spiral_scan_end);

    // Insert path — registered but body is an empty stub; TAM insert is not yet
    // implemented. Live writes reach Spiral via standard heap + track_changes_stmt trigger.
    (*routine).tuple_insert = Some(spiral_slot_insert);

    pgrx::datum::Internal::from(Some(pg_sys::Datum::from(routine as usize)))
}

Binary Packing & Direct Seeks: The Real Implementation

Spiral uses PostgreSQL’s own buffer manager — not flat files. The innovation is computing an exact (block_number, byte_offset) for any (t, tenant_id) pair in O(1), bypassing B-Tree traversal entirely.

Two core #[repr(C)] structures from src/storage.rs:

#[repr(C)]
struct CompressedBlock {
    first_val: f64,       // 8 bytes — anchor point
    data: [u8; 120],      // 60 × 2-byte XOR deltas (Gorilla encoding)
}                         // 128 bytes total → stores 64 time-series points

#[repr(C)]
pub struct SpiralPageOpaque {
    pub window_start_t: i64,  // time window covered by this page
    pub window_end_t:   i64,
    pub tenant_scale:   i32,  // number of tenant lanes
    pub magic:          u32,  // 0x50495241 = 'SPRA'
}

The address formula (mode 1 — direct f64, single value column):

Where t_rel = spiral(t) - kickoff_epoch normalizes any timestamptz to a dense integer. The offset then maps to a page via:

// src/storage.rs — exact implementation
const DATA_PER_PAGE: usize = (8192 - 24 - 24) / 8; // = 1018 f64 values per page

pub fn logical_to_physical_offset(logical_offset: i64) -> (u32, u32) {
    let index          = logical_offset / 8;
    let blkno          = (index / DATA_PER_PAGE as i64) as u32;
    let offset_in_page = (24 + (index % DATA_PER_PAGE as i64) * 8) as u32;
    (blkno, offset_in_page)
}

tenant_scale comes from a one-character cardinality hint: 'd'→10, 'h'→100, 'k'→1,000, 'M'→1,000,000, 'B'→1,000,000,000, 'T'→1,000,000,000,000.

Three Storage Modes: Matching Structure to Workload

Spiral ships three packing functions, each trading precision for density. The page map below shows exactly how each fills an 8KB page — and what the savings look like compared to a standard PostgreSQL heap table.

How to read the page map: Each small square = one 8-byte slot. A full page has 1024 slots arranged in a 32×32 grid.

The three pages shown side-by-side let you see how the tenant pattern repeats as data fills successive 8KB blocks.

Automating the Pipeline: Hierarchical Rollups

To make the system usable, I wanted to automate the creation of hierarchies. In Spiral, a single table definition with magic comments can generate an entire analytical pipeline:

CREATE TABLE asset_ticks (
    t timestamptz NOT NULL,
    price double precision, -- Spiral: ohlc, stats, sketch
    vol int                 -- Spiral: sum
);

Manual Control: Custom Hierarchies

While “Magic Comments” are great, power users can manually define rollups using standard Postgres MATERIALIZED VIEW syntax with Spiral options:

CREATE MATERIALIZED VIEW asset_ohlcv_1m 
WITH (
    spiral.frames = '5m,1h,1d',
    spiral.tenant = 'symbol_id'
) AS SELECT ... FROM ticks GROUP BY 1, 2;

Calendar-Aligned Rollup Tiers

Beyond fixed-second intervals, Spiral supports calendar-aligned tiers that snap to month, quarter, and year boundaries — essential for financial and business reporting where “monthly” means January 1st, not “30 days ago.”

CREATE TABLE asset_ticks (
    t         timestamptz NOT NULL,
    symbol_id int         NOT NULL,
    price     double precision, -- Spiral: ohlcv
    vol       bigint            -- Spiral: sum
) WITH (
    spiral.frames = '1h,1d,1mon,1qtr,1year',
    spiral.tenant = 'symbol_id'
);

Valid calendar suffixes:

Under the hood, calendar tiers use date_trunc('month', t) (or quarter/year) in the rollup GROUP BY, so they respect timezone-aware truncation. Fixed-second tiers (like 1h, 1d) use epoch arithmetic and are always UTC-aligned.

The Anatomy of a Rollup (Aggregation Inheritance)

How does Spiral know how to roll up your data? It uses deterministic rules for column inheritance:

Incremental Maintenance: Tracking Changes via Changelog

Standard materialized views require a full rebuild. Spiral explores Incremental View Maintenance (IVM) using a transactional changelog. Every update flags a specific time bucket as “dirty.”

A background worker written in Rust monitors this log and performs surgical updates—healing the “orbits” of the spiral without rebuilding the world.

// In src/worker.rs - The Healing Loop
pub fn perform_healing() -> Result<(), pgrx::spi::Error> {
    let dirty_buckets = Spi::connect(|client| {
        client.select(
            "SELECT start_t, end_t FROM spiral.changelog WHERE processed = false",
            None, None
        )?.map(|row| (row[1].value::<i64>(), row[2].value::<i64>())).collect::<Vec<_>>()
    });

    for (start, end) in dirty_buckets {
        // Surgical rollup for this specific bucket
        rollup_bucket(start, end)?;
        
        Spi::run_with_args(
            "UPDATE spiral.changelog SET processed = true WHERE start_t = $1 AND end_t = $2",
            Some(vec![
                (PgBuiltInOids::INT8OID.oid(), start.into_datum()),
                (PgBuiltInOids::INT8OID.oid(), end.into_datum())
            ])
        )?;
    }
    Ok(())
}

The Adaptive Query Slicer

One of the most complex parts of this research was exploring the PostgreSQL Planner Hook. The idea is to query the raw table and have the system automatically “slice” the query between different storage tiers based on data freshness and availability.

Select a time range on the timeline below, showing the last 7 days from past to present. Watch how Spiral would theoretically “slice” your query across storage tiers: Daily, Hourly, and Minutely rollups, with an automatic fallback to Raw Data for segments marked as “dirty” in the changelog. You can also simulate real-time traffic and see the background worker ‘healing’ the orbits.

Live Demo: The Modern Spiral Setup

Let’s see this in action using PostgreSQL’s native WITH syntax.

DROP EXTENSION IF EXISTS spiral CASCADE;
CREATE EXTENSION spiral;

-- The WITH clause tells Spiral to track this table,
-- set up specific rollups, and isolate data by 'sensor_id'.
CREATE TABLE sensor_data (
    t timestamptz NOT NULL,
    sensor_id int NOT NULL,
    temperature double precision, -- Spiral: ohlcv
    humidity double precision,    -- Spiral: sum
    power_usage double precision  -- Spiral: stats
) WITH (
    spiral.frames = '1m,1h',
    spiral.tenant = 'sensor_id'
);

Behind the Scenes: Auto-created Views

Spiral immediately registers the table and creates the hierarchical views.

SELECT view_name, parent_view, frame_seconds, scope_columns 
FROM spiral.metadata ORDER BY frame_seconds;

   view_name    |  parent_view   | frame_seconds | scope_columns 
----------------+----------------+---------------+---------------
 sensor_data    | BASE           |             0 | {sensor_id}
 sensor_data_1m | sensor_data    |            60 | {sensor_id}
 sensor_data_1h | sensor_data_1m |          3600 | {sensor_id}
(3 rows)

Notice it registered the base table and used the magic comments to build the 1m and 1h schema dynamically!

What You Get: SQL From Day One

Once the table is created and the first spiral_refresh runs, you get three things without writing any extra code:

1. Pre-aggregated views at every declared tier:

-- Raw sub-minute ticks
SELECT * FROM sensor_data WHERE sensor_id = 1 AND t >= now() - interval '5m';

-- 1-minute rollup — columns auto-derived from magic comments
SELECT t, sensor_id, temperature_ohlcv_o, temperature_ohlcv_h,
       temperature_ohlcv_l, temperature_ohlcv_c, humidity, power_usage_stats
FROM sensor_data_1m
WHERE sensor_id = 1 AND t >= now() - interval '1h';

-- 1-hour rollup for dashboards
SELECT t, sensor_id, temperature_ohlcv_h AS max_temp, humidity
FROM sensor_data_1h
WHERE t >= now() - interval '7d';

2. Transparent query routing — queries against sensor_data automatically rewrite to the right rollup tier.

3. Dirty-aware fallback — during a backfill or late-arriving data window, Spiral serves rollup for clean buckets and raw data for dirty buckets. Zero stale reads, zero full-table scans.

-- This is all you need to keep rollups fresh:
SELECT spiral_refresh('sensor_data');

-- Or scope to one tenant after a targeted backfill:
SELECT spiral_refresh('sensor_data', 'sensor_id = 3');

Data Ingestion spanning Timeframes

Let’s insert some raw data.

INSERT INTO sensor_data (t, sensor_id, temperature, humidity, power_usage) VALUES
('2026-05-03 20:15:00'::timestamptz, 1, 22.5, 45.0, 100.5),
('2026-05-03 20:15:00'::timestamptz, 1, 22.7, 45.2, 101.0),
('2026-05-03 20:15:00'::timestamptz, 2, 19.5, 50.0, 80.0),
('2026-05-03 20:16:00'::timestamptz, 1, 23.0, 44.0, 105.0),
('2026-05-03 20:16:00'::timestamptz, 2, 19.8, 51.0, 82.0),
('2026-05-03 21:15:00'::timestamptz, 1, 25.0, 40.0, 110.0);

Incremental Cascading Refresh

Refreshing the 1-minute rollup incrementally processes the new raw data.

SELECT spiral_refresh('sensor_data');

The column names are dynamically derived from the magic comments:

SELECT t, sensor_id, 
       temperature_ohlcv_o, temperature_ohlcv_h, 
       temperature_ohlcv_l, temperature_ohlcv_c,
       humidity, power_usage_stats
FROM sensor_data_1m ORDER BY t, sensor_id;

           t            | sensor_id | temperature_ohlcv_o | temperature_ohlcv_h | temperature_ohlcv_l | temperature_ohlcv_c | humidity |                              power_usage_stats
------------------------+-----------+---------------------+---------------------+---------------------+---------------------+----------+--------------------------------------------------------------
 2026-05-03 20:15:00+00 |         1 |                22.5 |                22.7 |                22.5 |                22.7 |     90.2 | {"n": 2.0, "m1": 100.75, "m2": 0.125, "m3": 0.0, ...}
 2026-05-03 20:15:00+00 |         2 |                19.5 |                19.5 |                19.5 |                19.5 |       50 | {"n": 1.0, "m1": 80.0, "m2": 0.0, ...}
 2026-05-03 20:16:00+00 |         1 |                  23 |                  23 |                  23 |                  23 |       44 | {"n": 1.0, "m1": 105.0, "m2": 0.0, ...}
 2026-05-03 20:16:00+00 |         2 |                19.8 |                19.8 |                19.8 |                19.8 |       51 | {"n": 1.0, "m1": 82.0, "m2": 0.0, ...}
 2026-05-03 21:15:00+00 |         1 |                  25 |                  25 |                  25 |                  25 |       40 | {"n": 1.0, "m1": 110.0, "m2": 0.0, ...}
(5 rows)

humidity is summed per minute bucket. power_usage_stats stores the Welford moments as JSONB — mean (m1), variance accumulator (m2), etc. — ready to merge up to the hourly tier without raw data.

Refresh cascades to the 1-hour rollup automatically because Spiral knows the hierarchy!

Partial Refresh by Tenant Scope

In high-cardinality deployments you often need to refresh only one tenant’s data — e.g., after a backfill for sensor_id = 3 without disturbing others. spiral_refresh accepts an optional WHERE-style scope predicate:

-- Refresh only sensor 3's dirty buckets
SELECT spiral_refresh('sensor_data', 'sensor_id = 3');

Spiral intersects that predicate with the changelog, processes only the matching dirty buckets, and leaves every other tenant’s rollup untouched. The changelog entries for other tenants survive the partial refresh and are picked up on their own schedule.

Transparent Query Acceleration

Spiral intercepts queries to the base table and rewrites them to use the pre-aggregated rollups seamlessly — no query changes needed.

-- You write this:
SELECT date_trunc('hour', t) AS hour, sensor_id, max(temperature)
FROM sensor_data
WHERE t >= '2026-05-03 19:00:00'::timestamptz 
  AND t < '2026-05-03 23:00:00'::timestamptz
GROUP BY 1, 2;

-- Spiral rewrites it to something like:
SELECT date_trunc('hour', t) AS hour, sensor_id, max(temperature_ohlcv_h)
FROM sensor_data_1h
WHERE t >= '2026-05-03 19:00:00'::timestamptz
  AND t < '2026-05-03 23:00:00'::timestamptz
GROUP BY 1, 2;

The rewrite selects the coarsest rollup tier whose granularity fits the query’s date_trunc(...). A 4-hour window that matches the 1h tier reads ~4 rows instead of potentially thousands of raw ticks — without any application-level change.

Multi-dimension GROUP BY acceleration. When the query groups by both a tenant column and date_trunc(...), the planner handles both dimensions together — matching the best rollup tier for the granularity, scoped to that tenant.

Z-order index push-down. For tenant-scoped rollup sub-queries, Spiral auto-injects a BETWEEN predicate on the z-order index:

-- Spiral rewrites this internally:
WHERE spiral_zorder(spiral(t), ARRAY['sensor_id'])
      BETWEEN <lo> AND <hi>

Z-order is monotone in t for a fixed tenant hash, so the BETWEEN exactly covers that tenant’s time range without scanning other tenants’ rows. This turns full-rollup scans into tight index range scans.

Multi-Table Acceleration: Join Constraint Propagation

The planner hook doesn’t stop at single-table rewrites. When Spiral detects an equijoin on t between two tracked tables, it propagates the time constraint from the constrained side to the unconstrained side, accelerating both simultaneously.

-- Two independent time-series, joined by time
SELECT s.t, s.sensor_id, s.temperature_ohlcv_h,
       a.asset_id,       a.price_ohlcv_h
FROM sensor_data s
JOIN asset_ticks  a ON s.t = a.t
WHERE s.t >= '2026-05-03 19:00:00'::timestamptz
  AND s.t <  '2026-05-03 23:00:00'::timestamptz;

Without Spiral: asset_ticks has no time predicate — full scan.

With Spiral: the planner walks the JoinTree, detects s.t = a.t, propagates WHERE t >= ... AND t < ... to asset_ticks, then rewrites both sides to their respective rollup tiers:

-- Effective plan:
SELECT s.t, s.sensor_id, s.temperature_ohlcv_h,
       a.asset_id,       a.price_ohlcv_h
FROM   sensor_data_1h s          -- ← accelerated
JOIN   asset_ticks_1h  a ON s.t = a.t   -- ← also accelerated via propagation
WHERE  s.t >= '2026-05-03 19:00:00'::timestamptz
  AND  s.t <  '2026-05-03 23:00:00'::timestamptz;

Both tables independently benefit from dirty-aware slicing. A dirty bucket in sensor_data does not force a raw scan of asset_ticks — each side is sliced independently against its own changelog.

Handling Late-Arriving Data

Let’s insert an hour of randomized, late data for all tenants.

INSERT INTO sensor_data (t, sensor_id, temperature, humidity, power_usage)
SELECT 
    '2026-05-03 22:00:00'::timestamptz + (random() * 60 || ' minutes')::interval,
    id,
    20 + random() * 10,
    40 + random() * 20,
    90 + random() * 30
FROM generate_series(1, 2) AS id, generate_series(1, 60);

Spiral tracks exactly which time buckets and tenants are “dirty”.

SELECT base_view, t_start, t_end, scope_values 
FROM spiral.changelog ORDER BY t_start;

  base_view  |  t_start   |   t_end    |   scope_values
-------------+------------+------------+------------------
 sensor_data | 1777856400 | 1777856460 | {"sensor_id": 1}
 sensor_data | 1777856520 | 1777856580 | {"sensor_id": 2}
 sensor_data | 1777856760 | 1777856820 | {"sensor_id": 1}
 ...
(76 rows)

Each row is one 60-second bucket per tenant. Only the buckets that actually received new data are marked dirty — the rest stay clean and will continue serving from the rollup.

Smart Query Slicing in Action

Spiral’s planner intercepts the query, consults the changelog, and rewrites to a UNION ALL that:

• routes clean hour-aligned buckets to sensor_data_1h (pre-aggregated, fast)
• routes dirty sub-minute windows back to sensor_data (raw, accurate)

-- You write:
SELECT date_trunc('hour', t) AS hour, sensor_id, max(temperature)
FROM sensor_data
WHERE t >= '2026-05-03 19:00:00'::timestamptz 
  AND t < '2026-05-03 23:00:00'::timestamptz
GROUP BY 1, 2;

-- Spiral actually runs (conceptual rewrite):
SELECT date_trunc('hour', t) AS hour, sensor_id,
       max(temperature_ohlcv_h) AS max_temperature
FROM sensor_data_1h                       -- ← pre-aggregated tier
WHERE t >= '2026-05-03 19:00:00'::timestamptz
  AND t < '2026-05-03 22:00:00'::timestamptz  -- 3 clean hours
  AND spiral_zorder(spiral(t), ARRAY['sensor_id'])
      BETWEEN 1777843200000000 AND 1777857600999999
GROUP BY 1, 2

UNION ALL

SELECT date_trunc('hour', t) AS hour, sensor_id,
       max(temperature) AS max_temperature
FROM sensor_data                          -- ← raw tier (dirty window)
WHERE t >= '2026-05-03 22:00:00'::timestamptz
  AND t < '2026-05-03 23:00:00'::timestamptz  -- 1 dirty hour
GROUP BY 1, 2;

The key insight: Spiral never re-aggregates clean data. The 3 clean hours each contribute exactly 1 row from sensor_data_1h. Only the dirty hour scans raw rows. As dirty buckets are healed, they graduate back to the rollup tier automatically.

Tier selection rules:

• A bucket is eligible for a rollup tier if it is aligned to that tier’s frame and clean in the changelog.
• The coarsest aligned tier wins (1h beats 1m, 1m beats raw).
• Adjacent segments from the same source are merged into one range scan to minimize plan nodes.

You can force EXPLAIN to show the rewrite:

EXPLAIN (VERBOSE)
SELECT date_trunc('hour', t) AS hour, sensor_id, max(temperature)
FROM sensor_data
WHERE t >= '2026-05-03 19:00:00'::timestamptz 
  AND t < '2026-05-03 23:00:00'::timestamptz
GROUP BY 1, 2;

The plan will show a HashAggregate over an Append (the UNION ALL) with separate SeqScan or IndexScan nodes — one per segment. After spiral_refresh, all four hours are clean and the plan collapses to a single scan of sensor_data_1h.

Healing the Orbits & Handling Deletions

We heal the dirty buckets. It only processes the changes!

SELECT spiral_refresh('sensor_data');

The entire time range is now clean. The same query now generates a single-tier plan:

-- After refresh, Spiral rewrites to a single rollup scan:
SELECT date_trunc('hour', t) AS hour, sensor_id,
       max(temperature_ohlcv_h) AS max_temperature
FROM sensor_data_1h
WHERE t >= '2026-05-03 19:00:00'::timestamptz
  AND t < '2026-05-03 23:00:00'::timestamptz
  AND spiral_zorder(spiral(t), ARRAY['sensor_id'])
      BETWEEN 1777843200000000 AND 1777857600999999
GROUP BY 1, 2;
-- 4 rows read instead of thousands of raw ticks.

If we delete data, it isolates the dirty fallback to ONLY the affected tenant (sensor_id = 1) for that specific time bucket — other tenants’ rollups stay pristine.

DELETE FROM sensor_data 
WHERE sensor_id = 1 
  AND t >= '2026-05-03 20:15:00'::timestamptz 
  AND t < '2026-05-03 20:25:00'::timestamptz;

SELECT base_view, t_start, t_end, scope_values 
FROM spiral.changelog ORDER BY t_start;

  base_view  |  t_start   |   t_end    |   scope_values
-------------+------------+------------+------------------
 sensor_data | 1777850100 | 1777850160 | {"sensor_id": 1}
 sensor_data | 1777850160 | 1777850220 | {"sensor_id": 1}
(2 rows)

Only sensor_id = 1 is dirty. sensor_id = 2’s rollups are completely untouched — a targeted dirty mark, not a full-table invalidation.

You can inspect the lag at any time:

SELECT * FROM spiral.status;

  base_view  | tier_count | dirty_entries | dirty_scopes | dirty_seconds | oldest_dirty_ts        | newest_dirty_ts        | lag
-------------+------------+---------------+--------------+---------------+------------------------+------------------------+-------------------------
 sensor_data |          2 |             2 |            1 |           120 | 2026-05-03 20:15:00+00 | 2026-05-03 20:17:00+00 | 21 days 01:23:37
(1 row)

lag tells you how stale your oldest dirty bucket is.

In a multi-tenant deployment, spiral.status aggregates across all tenants. For per-tenant visibility, spiral.scope_status breaks it down:

SELECT * FROM spiral.scope_status ORDER BY lag DESC;

  base_view  |    scope_values    | dirty_entries | dirty_seconds | oldest_dirty_ts        | lag
-------------+--------------------+---------------+---------------+------------------------+--------------------
 sensor_data | {"sensor_id": "1"} |            12 |           720 | 2026-05-03 20:15:00+00 | 21 days 01:23:37
 sensor_data | {"sensor_id": "2"} |             3 |           180 | 2026-05-03 22:10:00+00 | 20 days 23:05:12
(2 rows)

Sensor 1 has more dirty buckets than sensor 2 — a targeted spiral_refresh(‘sensor_data’, ‘sensor_id = 1’) heals only that tenant’s backlog without touching sensor 2.

For a single-number health check, spiral_lag() returns the lag as an interval:

SELECT spiral_lag(‘sensor_data’);
-- → 21 days 01:23:37   (NULL when fully current)

Pipe this into any monitoring system. NULL means clean; a growing interval means the worker is falling behind.

Autonomous Background Worker

You don’t need to call spiral_refresh manually. When spiral.frames is set, Spiral registers a background worker that wakes every second, claims dirty (base_view, scope) pairs from the changelog, and heals them — automatically.

-- postgresql.conf (or SET for session)
spiral.worker_enabled   = on    -- default: on
spiral.max_workers      = 2     -- parallel workers per DB
spiral.worker_batch_size = 10   -- scopes refreshed per 1s tick

Workers use advisory locks to divide scopes without conflicts: worker A refreshes sensor_id = 1, worker B refreshes sensor_id = 2 — no coordination overhead, no duplicate work.

The planner hook is similarly tunable:

spiral.enable_planner_hook   = on    -- disable to compare plans
spiral.planner_max_segments  = 50    -- fall back to RAW if UNION ALL would exceed N parts

When planner_max_segments is exceeded (highly fragmented dirty ranges), Spiral falls back to a full raw scan and logs a notice — trading query rewrite overhead for a simpler plan.

Mathematical Engine: Welford’s Algorithm

The Problem with Standard stddev()

PostgreSQL’s built-in stddev() cannot be rolled up. Given two pre-aggregated hourly stddev values you cannot compute the combined stddev without the original rows. This breaks the rollup chain.

Spiral needs a mergeable statistical state — one where rollup(rollup(raw → 1m) → 1h) gives the same answer as rollup(raw → 1h).

The Solution: Store Moments, Not Final Values

Welford’s online algorithm accumulates four central moments (n, m1, m2, m3, m4) rather than a computed stddev. From those moments you can derive mean, variance, stddev, skewness, and kurtosis at any time. Crucially, two StatsState structs can be merged exactly using Chan et al.’s parallel algorithm — no raw data needed.

The Rust Implementation (src/stats.rs)

// src/stats.rs
#[derive(Serialize, Deserialize, Default, Clone, Copy)]
pub struct StatsState {
    pub n:  f64,   // count
    pub m1: f64,   // mean
    pub m2: f64,   // sum of squared deviations  (→ variance)
    pub m3: f64,   // sum of cubed deviations    (→ skewness)
    pub m4: f64,   // sum of quartic deviations  (→ kurtosis)
}

impl StatsState {
    pub fn add(&mut self, x: f64) {
        let n1 = self.n;
        self.n += 1.0;
        let delta   = x - self.m1;
        let delta_n = delta / self.n;
        let term1   = delta * delta_n * n1;
        self.m1 += delta_n;
        self.m2 += term1;
        // m3 and m4 updated similarly — O(1) per value, numerically stable
    }

    // Chan’s parallel algorithm: merge two independent StatsState structs
    // Used when rolling up 1m → 1h → 1d without re-scanning raw rows.
    pub fn merge(&mut self, other: &Self) {
        let combined_n = self.n + other.n;
        let delta  = other.m1 - self.m1;
        let delta2 = delta * delta;
        let m1 = (self.n * self.m1 + other.n * other.m1) / combined_n;
        let m2 = self.m2 + other.m2 + delta2 * self.n * other.n / combined_n;
        // m3, m4 follow the same pattern with higher-order delta terms
        self.n = combined_n; self.m1 = m1; self.m2 = m2; /* ... */
    }

    pub fn mean(&self)     -> f64 { self.m1 }
    pub fn variance(&self) -> f64 { self.m2 / (self.n - 1.0) }
    pub fn stddev(&self)   -> f64 { self.variance().sqrt() }
    pub fn skewness(&self) -> f64 { self.n.sqrt() * self.m3 / self.m2.powf(1.5) }
    pub fn kurtosis(&self) -> f64 { self.n * self.m4 / (self.m2 * self.m2) - 3.0 }
}

How pgrx Hooks Connect Rust to PostgreSQL Aggregates

pgrx lets Rust functions register directly as PostgreSQL functions via the #[pg_extern] attribute. Spiral uses two functions to form a full PostgreSQL aggregate:

// Accumulation step — called once per raw row during spiral_refresh
#[pg_extern(immutable, parallel_safe)]
pub fn spiral_stats_accum(state: Option<pgrx::JsonB>, val: f64) -> pgrx::JsonB {
    let mut s = state
        .map(|j| serde_json::from_value::<StatsState>(j.0).unwrap())
        .unwrap_or_default();
    s.add(val);
    pgrx::JsonB(serde_json::to_value(s).unwrap())
}

// Combine step — called when merging two rollup tiers (1m → 1h)
// `parallel_safe` tells PostgreSQL this can run across parallel workers
#[pg_extern(immutable, parallel_safe)]
pub fn spiral_stats_combine(
    state1: Option<pgrx::JsonB>,
    state2: Option<pgrx::JsonB>,
) -> pgrx::JsonB {
    let mut s1 = state1.map(|j| serde_json::from_value::<StatsState>(j.0).unwrap())
        .unwrap_or_default();
    let s2     = state2.map(|j| serde_json::from_value::<StatsState>(j.0).unwrap())
        .unwrap_or_default();
    s1.merge(&s2);
    pgrx::JsonB(serde_json::to_value(s1).unwrap())
}

Why this fits the rollup architecture perfectly:

The -- Spiral: stats magic comment wires this up: when building a rollup view Spiral emits spiral_stats_accum(col) for the 1m layer and spiral_stats_combine(col_stats) for every higher tier.

Approximate Quantiles: Sketch and T-Digest

Welford gives exact moments (mean, stddev, skewness). But percentile_cont(0.95) cannot be rolled up — there is no exact mergeable form. Spiral provides two mergeable approximate quantile sketches instead.

Like stats, both store a JSONB blob at the 1m tier and merge it exactly as it rolls up to 1h, 1d — no raw data needed.

CREATE TABLE api_requests (
    t          timestamptz NOT NULL,
    service_id int         NOT NULL,
    latency_ms double precision -- Spiral: tdigest
) WITH (
    spiral.frames = '1m,1h,1d',
    spiral.tenant = 'service_id'
);

After refresh, the rollup stores latency_ms_tdigest at every tier. Query approximate percentiles at any granularity:

-- p50, p95, p99 from the hourly rollup — no raw rows needed
SELECT t, service_id,
       spiral_tdigest_quantile(latency_ms_tdigest, 0.50) AS p50,
       spiral_tdigest_quantile(latency_ms_tdigest, 0.95) AS p95,
       spiral_tdigest_quantile(latency_ms_tdigest, 0.99) AS p99
FROM api_requests_1h
WHERE t >= now() - interval '24h'
ORDER BY t, service_id;

This is the key advantage over standard PostgreSQL: a 1h bucket carries a compact sketch (~1 KB) that can answer any quantile query, and two hourly sketches merge into a daily sketch in microseconds. No raw rows ever need to be re-read.

Z-Order Indexing for Existing Tables

Spiral’s WITH (spiral.frames=...) wires everything automatically for new tables. For an existing table without Spiral TAM, cluster_table() creates the z-order index in one call:

-- Add z-order index to any table:
SELECT cluster_table('sensor_data', 't', ARRAY['sensor_id']);
-- Creates: idx_z_sensor_data ON sensor_data
--   USING btree (spiral_zorder(spiral(t), ARRAY['sensor_id']))

The planner hook then uses this index for BETWEEN pushdown on any query that filters by both t and sensor_id. No data migration, no DDL changes to existing schemas.

The spiral(t) function used inside the index is an identity for bigint and extracts the microsecond epoch for timestamptz. It exists so the index expression is stable regardless of which type t carries:

SELECT spiral('2026-05-03 20:15:00'::timestamptz);
-- → 1746303300000000  (microseconds since Unix epoch)

SELECT to_timestamptz(1746303300000000);
-- → 2026-05-03 20:15:00+00

Round-tripping through spiral() / to_timestamptz() lets you embed raw epoch arithmetic in SQL when needed — for example, to manually verify a z-order range or debug a planner rewrite.

Experimental Results: Prototype Benchmarks

In my local environment, with a 10 million row dataset, I saw results that justified continuing this research.

Building PostgreSQL Extensions in Rust: What I Learned

Spiral is built with pgrx — a framework that lets you write PostgreSQL extensions entirely in Rust. If you have ever wanted to extend PostgreSQL but found C intimidating, pgrx is worth serious attention.

The API Surface Spiral Uses

Every major PostgreSQL extension mechanism is available through pgrx:

What pgrx Makes Easy

Zero-cost type mapping. Rust f64 maps to PostgreSQL float8, i64 to bigint, Vec<Option<String>> to text[]. No manual Datum casting needed.

Memory safety in unsafe territory. PostgreSQL’s C API is deeply unsafe — raw pointers to pg_sys::Query, pg_sys::PlannedStmt, page buffers. pgrx wraps enough to make the common paths safe, while letting you drop to unsafe where needed (TAM scan callbacks, page manipulation).

Aggregate functions with combine support. The parallel_safe attribute on #[pg_extern] tells PostgreSQL the function can run across parallel workers — enabling automatic parallelism for rollup refreshes at no extra code cost.

What is Still Hard

The planner hook is raw C. planner_hook_type takes an unsafe extern "C-unwind" fn. Traversing pg_sys::Query, pg_sys::RangeTblEntry, and the JoinTree requires pointer arithmetic and intimate knowledge of PostgreSQL internals. pgrx does not abstract this — you read the PostgreSQL source to understand the node shapes.

TAM callbacks must not panic. Any Rust panic inside a TAM callback (scan_getnextslot, tuple_insert) crashes the backend. You must catch all errors before they unwind past the C ABI boundary.

Testing requires a running PostgreSQL. #[pg_test] spins up a real Postgres instance per test run. The setup is automatic with pgrx but CI times are longer than unit tests — integration is the only meaningful test boundary.

Starting Point for Your Own Extension

If you want to build a PostgreSQL extension in Rust:

cargo install cargo-pgrx
cargo pgrx new my_extension
cargo pgrx run pg17   # drops into psql with your extension loaded

The pgrx examples cover custom types, aggregates, operators, and background workers. Spiral’s source is also heavily commented — the TAM implementation in src/tam.rs and the planner hook in src/hooks.rs are good starting points for those two harder topics.

The PostgreSQL extension ecosystem needs more Rust. The barrier is lower than it looks.

Open for Collaboration

Building Spiral has been a rewarding learning experience. This is a work in progress. If you are a PostgreSQL internals expert, a Rustacean, or someone who loves high-performance storage, I invite you to contribute.

Spiral is open source. Check it out on GitHub and let’s explore the future of storage together.

Since then, the AI landscape has shifted massively, and the tools we use to navigate codebases have evolved. Today, I’m thrilled to announce a game-changing update to the fast gem: Model Context Protocol (MCP) Support for SQL.

Expanding Fast with MCP

We recently integrated full MCP support directly into the fast CLI. This allows modern AI assistants (like Claude, Gemini, or custom agents) to seamlessly interface with your SQL and Ruby codebase through structured, semantic queries rather than fragile regular expressions.

The new MCP server provides three incredibly powerful SQL tools:

1. search_sql_ast: Search SQL files using Fast AST patterns.
2. rewrite_sql: Preview structural SQL transformations safely.
3. rewrite_sql_file: Apply AST pattern replacements to SQL files in-place.

By coupling MCP with fast, AI agents can understand the deep semantic structure of your SQL queries, not just the text. They can find specific nodes (like create_hypertable in TimescaleDB) or locate poorly optimized queries, and even rewrite them autonomously.

The Problem: Massive CTE Duplication

Let’s look at a concrete optimization problem where AST analysis shines. In massive analytical queries, it’s common to use Common Table Expressions (CTEs) to organize logic. However, developers or ORMs often accidentally duplicate the inner logic of a CTE later in the query.

Consider this example:

WITH sales_2023 AS (
  SELECT region, SUM(amount) as total_sales
  FROM sales
  WHERE extract(year from date) = 2023
  GROUP BY region
),
top_regions AS (
  SELECT region
  FROM (
    -- This inner query is identical to the sales_2023 CTE!
    -- The database might re-compute this unnecessarily.
    SELECT region, SUM(amount) as total_sales
    FROM sales
    WHERE extract(year from date) = 2023
    GROUP BY region
  ) sub
  WHERE total_sales > 100000
)
SELECT s.region, s.total_sales
FROM sales_2023 s
JOIN top_regions t ON s.region = t.region;

This query re-compiles the exact same aggregation twice. In a large database, this is an expensive mistake.

Automating CTE Optimization with Fast

Using fast, we can write a script to automatically map all defined CTEs and then scan the rest of the AST to see if any subqueries are structurally identical to the CTEs we just declared.

Here is the Fastfile shortcut we built to prove the concept:

Fast.shortcut :find_duplicate_ctes do
  require 'fast/sql'
  file = ARGV.last
  ast = Fast.parse_sql_file(file)

  # Map all CTEs
  ctes = {}
  Fast.search('(common_table_expr ...)', ast).each do |node|
    name_node = node.search('(ctename $_)').first
    query_wrapper = node.search('(ctequery $_)').first
    if name_node && query_wrapper
      name = name_node.children.first # extract string name
      ctes[name] = query_wrapper.children.first # the actual select_stmt
    end
  end

  # Helper to recursively walk the AST for all SELECT statements
  def self.walk(node, results = [])
    results << node if node.respond_to?(:type) && node.type == :select_stmt
    if node.respond_to?(:children)
      node.children.each do |child|
        if child.is_a?(Array)
          child.each { |c| walk(c, results) }
        else
          walk(child, results)
        end
      end
    end
    results
  end

  # Compare inner subqueries against defined CTEs
  walk(ast).each do |node|
    ctes.each do |name, query|
      # Deep AST structural comparison ignoring whitespace formatting
      if node.to_s.gsub(/\s+/, ' ') == query.to_s.gsub(/\s+/, ' ') && node.object_id != query.object_id
        puts "Found duplication of CTE '#{name}'!"
        puts "Lines: #{node.loc.expression.first_line}..#{node.loc.expression.last_line}"
      end
    end
  end
end

Running this via fast .find_duplicate_ctes cte_example.sql instantaneously finds the duplicated logic without getting confused by varying indentation or line breaks.

The Future with MCP

With the fast MCP server, you no longer have to write these Ruby scripts manually every time. An AI assistant can perform the AST structural analysis for you on the fly.

We can instruct the AI to:

“Analyze all .sql files in the repository. Identify any subqueries that are identical to existing CTEs, and rewrite the file to use the CTE reference instead.”

The agent will leverage search_sql_ast and rewrite_sql_file to perform surgical, AST-aware refactoring that is magnitudes safer than any Regex approach could ever be.

Conclusion

The integration of MCP into the fast gem marks a significant milestone in how we interact with SQL and Ruby codebases. By providing AI agents with the ability to understand and manipulate ASTs directly, we unlock new levels of automation and optimization that were previously too complex or risky.

Whether you’re hunting for duplicate CTEs or refactoring legacy queries, the combination of structured analysis and AI intelligence makes the process faster, safer, and much more intuitive.

Happy hacking!

The No-Excuses Era

In my previous post, I shared the idea that we reached the no-excuses era, as we evolve and don’t have the same barriers we had before. Now, I focus on what we’re doing with our time and how this delegation is fragmenting and stretching the distance between those that are leveraging AI to become lazy and just reduce the working time, and on the other side, we have people that are really learning from it.

This is a classic problem of Time Economics. If we’re unloading the cognitive weight of low-level tasks, we must be intentional about how we reinvest that saved time. Are we investing it in “Future Value” activities—learning foundational concepts that AI still struggles with—or are we just increasing our consumption of “Low Authorship” reactive work?

So, if you’re learning fast with AI, what exactly are you learning? Are you just adding more skills, connecting agents, or are you really getting smarter?

Better prompts, a set of tools that will make you use less tokens? Settings that can be tweaked internally in the next interaction.

How do you judge it as you learn, and how is learning going to change as systems become more advanced and need less human input?

Are We Getting Smarter?

I’m curious about a few things:

• Am I just QA-ing for AI?
• Do we have a set of tools that needs to be created by humans?

I see AI will turn the full-stack developer into a holo-developer getting involved from conception, research, and validation to other areas.

The path you get is the path to fast adaptation. Find the gaps where AI is still not good and play hard with it. Get better and know exactly what you can leverage from it and what is still in your power as a proxy for the intent, holding the objectives, validating, and reiterating.

The Holo-Developer

I’m testing and validating the yoga app, and I’m certainly improving the way I interact, not only building better prompts but iterating better.

Every time you think about your wording and how it will impact the way the LLM sets the work for the agents. Every time you iterate over it and observe, learn, and understand the reasoning, you can use it faster and more accurately.

But use it for what? Now, it seems building systems will become far easier than in the past, so what new things are you going to build?

For some of us, programming is a drug. The dopamine hit of seeing code work is now amplified by AI speed. But if we’re just chasing that high without deep understanding, we’re not becoming better engineers; we’re just becoming more efficient addicts. The real challenge is maintaining the “thinking programmer” mindset when the tool can do most of the “doing.”

The Migration to Agentic Workflows

We’ll evolve our mindset to more agent-driven workflows, where we set the boundaries of the challenges and let AI decide and validate the options instead of thinking our mere single POV is worth everything.

Now, we’re in the migration to the agentic era. Fewer developers, higher throughput, easier to experiment, adopt, and reiterate.

So, if you’re not loading the same cognitive weight, where is your mind?

I don’t know how you feel when you see time flying but I feel it’s the best time ever to be a developer and see time being stretched immensely with the use of AI to build software.

I never feel so happy as when I have an idea and I can just code it at the speed of my ability to put it in words in detail.

When I don’t have all the words, most of it works very well for simple scenarios and it’s been amazing to prototype ideas.

Well, I’m a big fan of prototypes. I even had a company in the past that was solely dedicated to patents and prototypes, and we had built quite a few prototypes that involve hardware and software and sketching the main backbones of software behavior. I think my ability to document my steps was one of the most important steps in my career and it helped me to build my own authority online and become a big fan of documenting all the things.

I feel it’s never been easier to prototype and prove new ideas. In the past, even when we had good ideas, prototyping full scenarios was hard because we were overwhelmed by the amount of new things happening around us.

Now, I don’t feel we have excuses to not do things. For quite a while, several times in a week, we were surrounded by blockers like:

1. I got stuck on test coverage
2. I was not able to reproduce
3. I could not inspect it properly
4. I don’t know exactly how X works

Too long days where your energy was simply drained out from a big problem out of our scope domain, and now we can just learn it on the fly or rely on the expertise without going too deep.

What I love about it is that we have the ability to zoom in and out on every rabbit hole and choose topics and fill learning gaps, to become better and better engineers.

The ability to write your code with the AI should never surrender your cognitive perception but work to amplify it. Learn to filter what overwhelms and focus on continuing to learn.

Do you think just plugging more skills will make you smarter?

It’s not about installing more skills but better using them. Thinking more creatively on the future of our careers and how we’re expanding the potential into another scale.

If you get stuck, it does not take weeks but hours to move forward. Monthly achievements now are weekly and I love to see how agents are finally cooperating.

All big challenges seem like they’re becoming much easier to explore. To dive into the challenges, organize, brainstorm, understand alternatives and collaborate like a pro, you don’t need a big team, you can just sit with your favorite set of LLMs and have fun seeing your agents working and digesting, comparing, benchmarking, and trying to deeply get “the best” from your input.

Well, we have only a single valid excuse: we’ve reached the rate limit.

When you’re building an LLM agent to interact with a massive Rails codebase, giving it full file contents can quickly devour your token limits. A 2000-line model file isn’t just hard for humans to read; it’s expensive and noisy for an AI.

I wanted a way for LLMs to easily grab the “skeleton” of a file—just the class definitions, methods, validations, and associations—without reading every inner block of logic. And as I started building this, I realized it was also the perfect time to pay off some long-standing technical debt.

Dropping the parser Gem Dependency

For years, fast was married to the parser gem. It’s an incredible piece of software, but it has some downsides. It’s an external dependency that frequently needs to catch up with new Ruby syntaxes.

Recently, Codex, Claude and Gemini helped me to made a massive architectural shift: I removed the parser gem dependency entirely in favor of Prism (and Ruby’s native syntax parser).

This refactoring wasn’t just about reducing the dependency graph. It was about making fast leaner and deeply integrated with modern Ruby internals.

The best part? I managed to do this while keeping the core fast search API fully backward-compatible. All the node patterns you’re used to—things like (send (int _) :+ (int _)) or {int float}—continue to work effortlessly because fast elegantly adapts the Prism AST output back into the familiar parser-like node structures. Every single tutorial and script I’ve written over the years still works!

AST Folding: The LLM Token Saver

With the dependencies cleaned up, I focused on the LLM challenge: token efficiency. I introduced an AST folding feature (--level N) into the CLI.

To see it in action, let’s use RubyEvents as a playground and benchmark. Take the Talk model (app/models/talk.rb), which handles a lot of business logic. The regular file is massive:

• 723 lines of code
• ~23,000 characters

Dumping that straight into an LLM context is expensive and mostly noise. The AI doesn’t need the inner workings of def video_available? immediately—it just needs the class signature to understand the architecture.

When we use the .summary shortcut built into my local Fastfile (which leverages AST folding), we can generate a perfectly condensed skeleton of the class:

$ fast .summary ../rubyevents/app/models/talk.rb

Instead of thousands of lines, the agent receives a beautifully clean architectural map:

class Talk < ApplicationRecord

  WATCHABLE_PROVIDERS = [...]
  KIND_LABELS = {...}

  include Rollupable
  # ... (6 includes)

  belongs_to :event, optional: true, counter_cache: :talks_count, touch: true
  has_many :child_talks, class_name: "Talk", foreign_key: :parent_talk_id, dependent: :destroy
  # ... (30+ associations cleanly grouped)

  Scopes:
    without_raw_transcript
    with_raw_transcript
    for_topic(topic_slug)
    # ...

  Hooks: before_validation :set_kind, if: -> { !kind_changed? }

  Validations:
    :title, presence: true
    :date, presence: true

  Macros:
    configure_slug(attribute: :title, auto_suffix_on_collision: true)
    # ...

  def published?
  def video_available?
  def thumbnail_url(size:, request:)
  # ... (40+ method signatures without their bodies)
end

What just happened? Setting the proper folding levels provides extreme token savings for large language models:

1. No comments: We strip out comment clutter automatically. The LLM gets raw architectural design.
2. No deep details, only on-demand unfolding: All method implementations are suppressed, leaving only signatures.

The payload shrinks down to barely 130 lines (~4,300 chars). We get over an 80% reduction in tokens while retaining 100% of the class’s structure. If the agent decides it needs the deep details of video_available?, it can query for that method’s specific body rather than paying for the entire 700-line file.

MCP: Inline Experiments and Refactoring

To truly scale LLM-driven coding on huge Ruby projects, token savings aren’t enough; we need seamless interaction. That’s why I’ve repurposed fast’s core into an MCP (Model Context Protocol) server tool.

By exposing the .summary, .scan, and direct node-pattern queries to the LLM via MCP, we establish an interactive playground:

1. Navigating Big Codebases: Instead of cating huge files, the agent uses .scan across lib or app/models.
2. Inline Experiments: The AI uses fast patterns to test assumptions against the live AST.
3. Refactoring Confirmation: When the LLM proposes a structural mutation, it uses the MCP loop to confirm structurally what it will change. Because fast understands the AST, the agent can dry-run a rewrite and verify the updated output—applying precise, safe updates recursively without context bloat or syntax hallucination.

I see more and more that the bottleneck for AI isn’t capability; it’s the quality of the context we feed it. By trimming the fat with AST folding and exposing a dependency-free core through MCP, fast is turning out to be one of the best sidekicks an AI agent could ask for.

If you are exploring agents and working with Ruby, give it a try and feel free to reach out. I’m having a blast building this foundation.

Happy hacking!

Jônatas Davi Paganini

• ideia.me
• github.com/jonatas
• linkedin.com/jonatasdp

Before We Start — A Question

Raise your hand if you’ve used software today.

Now keep it raised if that software made a decision about you — what you see, what you’re offered, whether you qualify for something.

That’s what we’re here to talk about. You’re learning to build the thing that just raised everyone’s hand.

The code you write will touch people you’ll never meet, in situations you never imagined.

Who Am I

• Developer since 2004
• Worked across Brazil and internationally, mostly remote
• Currently Senior Software Engineer at Hubstaff
• Previously Developer Advocate at Timescale — time-series data
• Passionate about open source, teaching, and living close to nature
• Building a permaculture farm while writing database code

→ ideia.me/resume

A Frame: Three Permaculture Ethics

Before we talk about code — a small detour into farming.

Permaculture is a design philosophy for sustainable human habitats modeled on nature. A forest garden doesn’t need watering, pesticides, or weekly maintenance. You design with nature, not against it.

Its foundation is three simple ethics:

• Earth Care — protect and restore natural systems
• People Care — support human wellbeing and community
• Fair Share — distribute surplus, limit consumption

I’ll use these as a lens throughout this talk. Because they map surprisingly well to software.

Time Is Your Most Valuable Resource

(People Care starts with you)

• You have finite hours — every line of code costs time
• Learning something once vs. doing something manually 1000 times
• Automation is fundamentally about reclaiming human time

Time Economics: think about the return on your time investment.

→ ideia.me/time-economics

What to Build Matters

• Not all software is worth building
• Who benefits? Who pays the hidden cost?
• The why behind your code shapes its impact
• Aligning your work with your values is a career strategy

Your choices about what to build matter as much as how to build it.

What Does Ethics Mean in Computing

(People Care at scale)

• Who benefits from the software you write?
• Who is excluded or harmed?
• Ethics isn’t a feature — it’s a design decision from the start
• The consequences of code extend far beyond the codebase

Bias in Algorithms

• Algorithms trained on biased data reproduce that bias
• Real-world examples: hiring tools, credit scoring, predictive policing
• “Neutral” systems are rarely neutral
• Bias compounds over time and scale

If your training data reflects injustice, your model will too.

Privacy & Data Power

(Fair Share — who controls the resource?)

• Data collected is power held over users
• Most users don’t read privacy policies — and companies know it
• Data breaches are not just technical failures, they’re ethical ones
• Minimum viable data: collect only what you truly need

The “Move Fast” Problem

• “Move fast and break things” has real victims
• Speed at scale means mistakes affect millions
• Responsible engineering includes slowdowns for review
• Ethical debt is harder to pay than technical debt

The “move fast” motto was never meant for systems that touch real lives.

The Scale of the Problem

(Earth Care — the invisible infrastructure)

• Global data centers consume ~1–2% of world electricity
• That’s comparable to the entire aviation industry
• Demand is growing faster than renewable capacity
• Software is invisible infrastructure — but it has a physical footprint

AI & Energy

• A single large AI training run can emit as much CO₂ as 5 cars over their lifetime
• Inference at scale is also costly — every query has an energy cost
• Crypto mining and NFTs: enormous computation, narrow benefit
• Streaming video: largest share of global internet traffic

Efficient Code Is Green Code

• Your choice of algorithm literally affects the planet
• O(n²) vs O(n log n) isn’t just academic — at scale it’s energy
• Use efficient queries — don’t load what you don’t need
• Avoid spinning up cloud resources you don’t actually need
• Renewable energy is growing — but demand is growing faster
• “Carbon neutral” claims often rely on offsets, not reduction

Every CPU cycle is a tiny combustion. Write thoughtful code.

Permaculture Principles Side by Side

The three ethics show up everywhere in software — once you learn to see them.

The Mapping Holds

• Earth Care → write efficient code, minimize waste, think about the full compute lifecycle
• People Care → build for real users, protect their data, avoid systems that harm
• Fair Share → open source, accessible tools, don’t hoard data or power

Sustainable design in nature and sustainable design in software come from the same instinct: don’t take more than you give back.

Remote Work Reduces Emissions

(Earth Care in your daily work life)

• Commuting is one of the biggest individual CO₂ sources
• Remote work eliminates daily travel for millions of people
• Less office space = less heating, cooling, and construction
• It enables working from places with lower cost of living or closer to nature

→ ideia.me/disciplina-no-home-office

Paths That Combine Code & Values

• Environmental tech: climate modeling, energy grid optimization, precision agriculture
• Open source: building public goods, not just private products
• Education tech: democratizing access to learning
• Health informatics: data that saves lives when handled responsibly
• Policy & regulation: CS people are needed in government too

You don’t have to choose between a meaningful career and a technical one.

The Ethical Developer Checklist

Start Now

• Learn to estimate the computational complexity of your code
• Use efficient queries — don’t load what you don’t need
• Read the privacy policies of the apps you build (and use)
• Contribute to an open source project you care about
• Choose an employer whose values match yours

The best time to think about ethics is before you write the first line.

Long-Term Habits

• Build a practice of asking “who is harmed?” before shipping
• Stay curious about the social context of the systems you work on
• Join or create communities that take ethics seriously
• Advocate internally — developers have more influence than they think
• Keep learning: CS ethics is a growing field with real careers

You’re Early

You haven’t shipped a broken hiring algorithm yet. You haven’t collected data you didn’t need yet. You haven’t written O(n³) code running on a million requests yet.

You’re at the beginning. That’s a gift.

The developers who shaped the internet mostly learned these lessons after the damage was done. You get to start with them.

The field needs people who care about what they build, not just how they build it. That’s you — if you choose it.

Let’s Talk

Jônatas Davi Paganini

• ideia.me
• github.com/jonatas
• Senior Software Engineer at Hubstaff

What questions do you have?

This project, however, was about more than just web development. Over the last few nights, I’ve been testing and integrating with the Antigravity platform—using it to rescue a graveyard of abandoned, hard-to-maintain old projects and migrating them into a brand-new Apps section on this website. I wanted to bring their essence back to life.

Building this animated yoga app became my way to deeply test the Antigravity platform. I am leveraging my curiosity to learn more about the things I feel attracted to—mixing my personal interests in yoga and math with code. I am absolutely loving the new capabilities and interactions this process is unlocking.

If you’ve ever tried to animate a vector graphic from scratch, you know the struggle: limbs detach, elbows bend the wrong way, and figures often look like they’re breaking apart mid-animation. But the solution here wasn’t a heavy JavaScript animation library. It was pure geometry.

By anchoring an SVG figure correctly and relying entirely on CSS rotational variables, you can create a skeleton that inherently understands its own joints.

The Coordinate System

To understand how the stickman moves, we first need to understand the SVG coordinate system. Unlike standard Cartesian math where the Y-axis goes up, in an SVG, the Y-axis goes down.

This flips our intuition for rotation. If you point a line straight down (the positive Y-axis) and apply a positive rotation in CSS (transform: rotate(90deg)), it rotates clockwise—meaning the line swings out to the left (the negative X-axis).

Understanding this flipped rotational space is critical when positioning our figure for complex asymmetrical poses.

Structuring the Joints

Instead of redrawing paths for every pose, our stickman is built once using <g> (group) elements. Every limb acts as a nested pendulum.

For example, the arm is built like this:

<g id="upper-arm" style="transform-origin: shoulder-X shoulder-Y; transform: rotate(var(--upper-arm-rot))">
    <line ... /> <!-- The actual bicep -->
    <g id="lower-arm" style="transform-origin: elbow-X elbow-Y; transform: rotate(var(--lower-arm-rot))">
        <line ... /> <!-- The forearm -->
    </g>
</g>

By placing the transform-origin exactly at the joints, the lower-arm automatically travels wherever the upper-arm goes. When the --upper-arm-rot changes, the entire nested group swings flawlessly.

Try it out here:

The Trigonometry of Chaturanga

Defining a standing pose is easy—you keep everything roughly at zero. But what happens when the body needs to hover entirely above the floor, supported only by the hands and toes?

In Chaturanga Dandasana (Low Plank), the body must form a perfectly rigid incline plane. Since the toes rest on the floor (Y = 368) but the arms are bent 90 degrees at the elbow, the shoulders hover slightly lower than the hips.

Here is the math I used to solve this so the figure perfectly connected its toes and hands to the mat:

1. Calculate the Vertical Drop: The upper arm goes straight back, and the lower arm goes straight down. Since each arm segment is 60px, the vertical drop from Shoulder to Hand is exactly 60px.
2. Find the Slope: If the hands are at the floor (Y = 368), the shoulders must be exactly at Y = 368 - 60 = 308. The toes are also at the floor (Y = 368). This means the body drops 60 vertical pixels over its entire length.
3. Trig to the Rescue: The length of the Torso (100px) + the Legs (160px) creates a hypotenuse of 260px.

Because we know the opposite and the hypotenuse, we can solve for (\theta):

Taking the arcsine gives us our angle:

Because the torso points up from the hips, and the hips sit in the middle of our 260px line, we can apply this 13.34° absolute rotation directly to the Torso and Legs:

• The Torso points Right (90° from UP), tilted up by 13.34° = 76.66°.
• The Legs point Left (-90° from DOWN), tilted down by 13.34° = 76.66°.

When you apply these calculated CSS angles, the stickman seamlessly lowers itself into a geometrically flawless plank.

Math doesn’t just ensure algorithms run efficiently; it gives us the power to orchestrate beautiful physical geometry. Take a look at the final Yoga Poses application to see the full Ashtanga sequence running entirely on these trigonometric angles!

Then, I need to track the work and I get some insights about the way I work.

That was the easy part, software showing me metrics about how I’m doing my work, how much I’m active, how much I’m focused and so on.

But now, in the third week, I already see so many benefits of tracking and committing to the time I was expected to work.

Well, for me distraction means I’m lacking meaning and I just get distracted when I’m unsatisfied or use distraction to control my anxiety.

But now I’m looking to the validation model that my brain is offering me. Yes, I see myself more validated by the time as time is the first commitment expected when you have a job. Later come, focus, deliveries and goal achievements.

I feel I work purely disconnected to the work when I leave the computer. I know I’m not tracking my time. This is a very important factor on my brain. If I’m really not working, I’m not working.

I was really not expecting that, but as the timer keeps rolling during the day I got myself thinking much less in work and much more in optimize my free time as I optimize my daily time.

In my off work week schedule, I have:

Monday 1.5 hours of night workout. Tuesday 2 hours of Yoga. Wednesday I split between Kayaking or land work. Around 2 hours. Thursday 1 hour gym. Friday 2 hours in the waterfall near by my house. I rest and always have some yoga there.

I’m always looking for ways to optimize and use very well my time. It takes 40 min to round trip to the city I do my exercises. As I live in the country side, and it’s around 47 km to round trip to my appointments.

So, when I’m going, most of the days I’m heading to a Yoga class, and my mind already start watching the mind state purely.

I see my selective brain working, moving from repressive thoughts about my performance with ok, I did my part, I focused all the time I promised and now I’m engaging on my personal life.

It takes time to make it, but I observed that this time tracker is helping me to remember about what I’m doing and what was my days. In the past few months I did several days of 10-12 hours in the computer and felt regretful to invest too long hours.

That was not healthy and it was just driven by the validation that we need to live and feel belonging. It starts with your mom saying yes or no and then family, teachers, and later co-workers.

When the company culture is purely async, you don’t feel this validation. Nobody is chasing to find you online, or value your instant answer. Your commitment is just based on your actions, the way you interact and move your tasks forward.

I absolutely love it. This relief the stress of thinking about “being available” and open room for “being focused”. I always admire the way we shape our focus and now I feel this small rewarding numbers that we chase everyday, worked as the validation I was looking for.

I’m not here to convince it will work for you, but I feel that when I was not tracking my time I was always working more, thinking more about work in the off-working hours and never empowering my real creative idleness. Because I don’t have any previous evidences or metrics, and the absence of human validation makes me fall into a psychological trap to reduce my perception of my efforts.

I think that my work-mind relationship now is much healthier just because I found a way to say, ok, I did it!

And no, I haven’t watched the series Severance but I know it exists ;)

Holotropic breathing — a technique developed by psychiatrist Stanislav Grof — involves sustained, rhythmic, deep breathing that induces altered states of consciousness. A facilitator leads the session. You lie down, close your eyes, and breathe intensely for extended periods. Strange things happen to the body and mind when you flood them with oxygen for that long. Some people cry. Some laugh. Some report visions.

What happened to me was arguably funnier than any of that.

About four hours in — or so I thought — I was completely conscious. I could feel my legs on the floor. I could hear the music in the room. I was breathing hard, present and standing, fully engaged in the exercise. I was not having visions. I was just here, aware, going through it.

Then someone tapped my shoulder.

I opened my eyes. I was lying on the mat. It was over an hour later than I thought. I had been asleep for more than an hour — not the gentle, drowsy kind of sleep, but the fully unconscious, gone kind — and my body had somehow maintained the posture of standing in the exercise, in my mind, the entire time. A lucid dream so complete that I had no awareness of being anywhere other than exactly where I thought I was.

I have never been so confused about the location of my own body.

That experience planted something. The idea that breath could carry consciousness somewhere else entirely — that it was not just gas exchange but a lever for the whole nervous system — stayed with me even as I filed it under “weird twenties stuff” and moved on.

Four years ago I started practicing yoga seriously. And yoga is, in many ways, just structured breathing with movement attached. Every pose is an invitation to track where the breath goes, how it changes when you are in discomfort, what happens when you consciously slow it down. I have been doing this four days a week for years now.

And I still struggle. Not with the poses. With the breathing itself.

Sitting in meditation, just watching the breath — no technique, no count, just observation — is deceptively hard. The mind wanders in about four seconds. You bring it back. It wanders again. You spend the whole session not meditating but noticing that you stopped meditating, which is, apparently, still the practice. My teacher tells me this is fine. I believe her and also remain annoyed by it.

What I have found useful is that when pure observation is too slippery, a technique gives the mind something concrete to hold onto. A count. A rhythm. A physical shape to follow. The breath becomes a task, and the mind, which loves tasks, actually pays attention.

Here are seven techniques in the order I’d suggest learning them. Each one is slightly more involved than the last. The animations below are interactive — click the circle to begin, click again to pause.

1. Belly Breathing — The Foundation

Before any technique, there is the question of where the breath lands.

Most people under stress breathe into the chest. Shallow, fast, the collarbones rising. That pattern signals urgency to the nervous system, which responds accordingly. Belly breathing — drawing air into the diaphragm so the belly expands outward on the inhale — does the opposite. It activates the vagus nerve and tells the body it is safe.

To find it: lie down, one hand on your chest, one on your belly. Inhale. The hand on your belly should rise; the one on your chest should barely move. That is it. That is the whole thing.

It sounds obvious. Under stress, when the chest-breathing pattern is most ingrained, it is also the hardest to access. The animation below uses 4-second counts — slow enough to feel the expansion, fast enough to be comfortable.

Once this is natural, every other technique works better. You are breathing correctly first, then adding rhythm on top.

2. Physiological Sigh — The Instant Reset

This one takes about ten seconds and requires no practice at all.

A physiological sigh: one normal inhale through the nose, then immediately a second shorter inhale on top of it — filling the lungs completely — followed by a long, slow exhale through the mouth.

The double inhale is the whole mechanism. Your alveoli — the small air sacs in the lungs — partially collapse when you are under stress or have been breathing shallowly for a while. The second inhale pops them open. The long exhale then drives out accumulated CO2 and activates the parasympathetic system hard.

Andrew Huberman at Stanford calls this the fastest known way to reduce acute physiological stress. The body does it spontaneously when crying, which is why crying reliably makes you feel less terrible — it is not the tears, it is the breathing pattern they come with.

3. The 3-2-5 — Gentle Calming

Inhale for 3 seconds, hold for 2, exhale for 5.

The extended exhale is the mechanism. A longer exhale than inhale shifts the autonomic nervous system toward parasympathetic — rest, digest, not fight-or-flight. The hold lets oxygen exchange fully before you release. The short inhale keeps things manageable without a feeling of overbreathing.

Ten rounds takes about ninety seconds. Good for anytime the body is tense for no reason you can identify.

4. Box Breathing — Symmetry and Focus

Four equal sides: inhale 4 seconds, hold 4, exhale 4, hold empty 4.

The symmetry is deliberate. Equal phases force a mental regularity that interrupts thought loops. You cannot be scattered and also be carefully counting to four across four phases at once.

The part people consistently forget is the second hold — the pause after the exhale, lungs empty. It feels uncomfortable. That discomfort is the point. You are training the nervous system to tolerate a gap without panicking into the next inhale.

Reportedly used by Navy SEALs before high-pressure situations. Five rounds takes about two minutes.

5. Resonant Breathing — Coherence

The target: approximately 5.5 breaths per minute. About 5.5 seconds inhale, 5.5 seconds exhale, no holds.

Research on heart rate variability suggests that breathing at this exact rate synchronizes the cardiovascular and respiratory systems in a way that maximizes nervous system resilience and adaptability. Most people at rest breathe 12 to 20 times per minute. Slowing to 5.5 feels strange at first — the inhale seems too long, the exhale never quite enough — and then the body adjusts and it feels more like the breath it was supposed to be taking all along.

A simple entry: inhale to a slow count of five, exhale to a slow count of six. Close enough to the target. Five minutes and the effect is cumulative — a settling, like water that was disturbed going still.

6. 4-7-8 — For Sleep and Deep Anxiety

Inhale 4 seconds, hold 7, exhale 8.

The proportions matter more than the absolute seconds. The long hold — 7 counts — builds a small amount of CO2 in the bloodstream. This is counterintuitive: CO2, the thing you are trying to expel, in the right concentration triggers a calming response. The exhale at nearly double the inhale then pushes the nervous system hard toward rest.

It can make you slightly light-headed the first few times. This is normal. Four rounds is usually enough to feel the effect.

7. Alternate Nostril Breathing (Nadi Shodhana)

This one comes from yoga and feels strange to describe — it is also the kind of thing you probably do not want to do in a meeting.

The cycle: close the right nostril with the right thumb, inhale through the left for 4 counts. Close both briefly. Release the right, exhale through the right for 4 counts. Inhale right for 4 counts. Close both. Exhale left for 4. That is one full round.

The physiological claim is that it balances activity between brain hemispheres. I cannot verify that and I am skeptical of single-mechanism explanations. What I can say is that it produces a distinctive quality of focused calm — possibly because attending to which nostril you are using requires enough specific attention that the rest of the mental noise has nowhere to go. It just has to stop for a minute.

The asymmetry keeps the mind engaged. There is no autopilot available here.

The holotropic experience — the one that started this — is something I would not recommend casually. It is not a technique you do at your desk. It requires a trained facilitator, a safe setting, and a willingness to not know where your body is for a while. I mention it here because it was, for me, the proof-of-concept: breath has reach. It touches places in the nervous system that logic and intention do not easily access.

The seven techniques above are not that. They are quieter, more portable, more everyday. But they are on the same continuum. Same lever, smaller pull.

The practice is noticing. The technique is just what you do after you notice.

We breathe about 20,000 times a day. Most of those are fine without any intervention. It is the moments when the breath is holding something — tension, dread, the vague weight of being slightly behind — where it helps to have a tool. And it only takes one deliberate breath to remember that the rest of the body is still here, still fine, still breathing.