A year of Postgres, on us
Three growth programs, one mechanism. Startups get twelve months of Ship free, partners get 30% off across five client workspaces, and any workspace can refer another for free months on both sides. All of it is a discount on the ordinary plans - no special tier, no credit balance, no catch we could find.
The offer
Three programs open today.
CapyDB for Startups. Early-stage teams - founded in the last five years, fewer than 25 people, under five million raised, building a product on Postgres - get twelve months of the Ship plan at no charge. That is three production cells, five preview databases each, import, restore, credential rotation, and the plan's full compute envelope. At the published price it is about $190 of managed Postgres. Apply.
Partners. Agencies, consultancies and freelancers who run Postgres for clients get 30% off Vibe and Ship for twelve months, redeemable on up to five client workspaces. Each client is its own organization with its own bill and its own cells; you are a member, not the account holder. Apply.
Referrals. Every workspace now has a share code. A workspace that signs up with it gets two free months instead of the standard one; when it pays its first invoice, the referrer's next month is free. No cap on either side. It is on the billing page of any workspace you manage. How it works.
The mechanism, because that is the interesting part
We spent more time on the shape of these than on the numbers. The question was how to grant a year of Postgres without inventing a parallel billing system that would drift from the real one.
The answer was to not invent one. Every program is a discount at the billing provider, applied at checkout on the ordinary plans:
- The startup code is a 100% discount, scoped to the Ship product, repeating for twelve cycles, one redemption. The twelfth free invoice is the last one it covers; the thirteenth is the first you pay, at the published price, on the card you gave at checkout.
- The partner code is a 30% discount, scoped to Vibe and Ship, repeating for twelve cycles, five redemptions.
- A referral code is a 100% discount for two cycles, unlimited redemptions but one per customer. The referrer's reward is a separate one-cycle discount attached to their own subscription the moment the referred workspace's first real invoice is paid.
That decision does a lot of work. There is no credit ledger to reconcile against invoices. There is no "program tier" whose limits could quietly differ from the plan's. A workspace on the startup program is a Ship workspace, full stop, and every guarantee on the pricing page applies to it. When a code expires or runs out, the plan simply bills normally - nothing to migrate.
Two consequences we made deliberate rather than accidental:
A code replaces the free month; it does not stack. Every self-serve plan opens with a one-month trial. If codes were entered on the payment provider's own form, a startup would get thirteen months, a referred workspace three, and the referrer would wait an extra month to be rewarded. So checkout disables the trial when a code is applied, and disables typed codes at the provider entirely. Codes go through the CapyDB billing page, and only there. Twelve months means twelve months.
Referrals are attributed to workspaces, not people. A referred workspace can be referred once, by whichever code it redeems first; a code is refused on the workspace that owns it; and the reward needs an active subscription to land on, or the referral is marked void with the reason. The referrer is never told who signed up and the referred workspace is never told what was earned. The introduction stays between you.
What the operator side looks like
An application is one form: company, stage, team size, and a few sentences about the product. It lands in the control plane through a service token that can do exactly one thing - file an application - and the applicant gets a receipt in their own language. A person reads it. A decision creates the discount, records the code against the application, and sends the email; deciding an already-decided application is refused, so two operators cannot issue two codes.
The reward side runs on two webhook events from the billing provider and is idempotent against redelivery: attribution returns the existing referral, and the reward is a single-winner claim on the control plane, so a retried event finds nothing left to reward.
Everything above is in the guide, and the referral endpoints are in the API reference and the SDK.
Why now
Because the product is at the point where the thing we want most is more real workloads on it, from the kinds of teams who tell us bluntly what is wrong. A year of Ship costs us little and buys exactly that. If you are building something on Postgres and the shape fits, apply. If it does not quite fit and you think it should, apply anyway and say why - the form is read by the same people who will answer.
A database your agent cannot destroy
A growing share of projects are started by a coding agent and only reviewed by a person. Here is what CapyDB publishes so the agent can hand that person a working database, what the agent cannot do, and why none of it needed anything new.
Break the chains: your RLS policies can leave Supabase
Row-level security is usually the reason a project cannot move off Supabase - not the policies, but the auth context under them. capyrls converts that layer to plain Postgres, in your terminal or in your browser, and tells you what it could not convert.