Structured Query Geometry

A good data model is like a concrete wall: it should be solid, visible, and raw. We often try to hide the complexity of our data behind layers of abstraction (ORMs, views, microservices), but sometimes, you just need to see the raw SQL.

The Brutalist Approach

Brutalism in architecture is about honesty of materials. You don't paint over the concrete; you celebrate the texture of the formwork. In data engineering, this means exposing the structure.

Raw SQL as Truth

Consider this query. It doesn't hide behind an ORM. It declares exactly what it wants:

WITH user_cohorts AS (
    SELECT 
        DATE_TRUNC('month', created_at) as cohort_month,
        user_id
    FROM users
    WHERE status = 'active'
),
retention AS (
    SELECT
        c.cohort_month,
        COUNT(DISTINCT c.user_id) as cohort_size,
        COUNT(DISTINCT CASE WHEN a.activity_date > c.cohort_month THEN c.user_id END) as retained_users
    FROM user_cohorts c
    LEFT JOIN activity_logs a ON c.user_id = a.user_id
    GROUP BY 1
)
SELECT
    cohort_month,
    cohort_size,
    retained_users,
    (retained_users::float / cohort_size) * 100 as retention_rate
FROM retention
ORDER BY 1 DESC;

Principles of Structural Data

1. Expose the IDs: Don't hide the primary keys. They are the rebar of your structure.
2. Denormalize with Purpose: Sometimes, a massive, wide table is exactly what you need for analytics. Don't be afraid of it.
3. Immutable Logs: Treat data as a stream of events that cannot be changed, only appended to.

When you stop fighting the nature of the database, you find a strange kind of beauty in the rows and columns.