Everything your AI agents need to build seriously fast, live analytics on top of your Postgres: query 100M+ rows in milliseconds, through an API that gives your agents the context behind every column.
You connect it — one command — describe the data you want to present, and query it. Mason does the replicating and the optimising — continuously, without being asked.
One command. Mason asks for what any logical replica asks for and nothing more, streams from a standby if you have one, and copies only the columns you publish. Nothing on production changes.
A logical model is a short file: the rows, what is measured over them, how fast and fresh it must be — and a description on anything a person or an agent could misread. Joins come from your foreign keys. Nothing about storage. The descriptions travel with the data into every API response and every MCP tool call.
Changes stream in from your primary and are routed to exactly the partitions that depend on them — not the whole table, and not everything downstream. A new order lands in seconds, and is in every model that uses it about half a minute after it was placed.
One call: a model, its metrics and what to group them by. Row-level security comes from a token your server mints for the signed-in user — it says what they may see, and a filter Mason can't apply refuses the query instead of widening it. Your agent reads the model's descriptions over MCP and writes the same code you would.
mason-token.ts mints a token for the
signed-in user's organization, and revenue.tsx
queries with it — so each customer sees only their own
orders.
Every query that arrives tells Mason something. It pre-aggregates what gets grouped, partitions what gets filtered by time and indexes what gets looked up — then measures each against its target, and proposes removing what nothing reads any more.
It's a logical replica, so the questions are the ones you'd ask of any: what it needs, what it costs, how far behind it runs, and what happens when it's gone.
What any logical replica needs: wal_level = logical,
a publication listing the tables and columns to copy, a
replication slot, and a role with REPLICATION. No
superuser, no extension, no schema change. Self-hosted, RDS,
Aurora, Cloud SQL, Supabase and Neon all qualify.
Streaming reads the WAL your primary already writes. On Postgres 16 or later Mason can stream from a standby instead, so the primary does nothing extra at all. History is copied once, in bounded windows that can be paused and resumed.
Rows are queryable about 15 seconds after they commit, and in every model that uses them about half a minute after — measured end to end against a 190-million-row production table taking a write every half second. Seconds behind, not the hours a nightly export costs.
Your application never notices: Mason isn't in your write path.
The replication slot keeps WAL on the primary until Mason catches
up, so no change is lost. Set max_slot_wal_keep_size
to cap how much it may hold — past that, Postgres drops the slot
and Mason copies again.
One command against a standby, and nothing on production changes. If it isn't faster than what you have today, you've lost an afternoon.