foundations
Star
Copy and paste

Recipes

Whole pages instead of single components. Each recipe is a complete file importing from the package alone, so it compiles as soon as you paste it into your app.

The code tab is the file itself

Each recipe is read off disk at build time, from the same file that rendered the preview beside it. The code you copy is the code that ran.

Marketing hero

An eyebrow, a display heading, a lede and a feature grid. The file sets layout and leaves every size, weight and colour to the ramp, so one copy renders correctly on both surfaces.

Warehouse sync

Your data, in the warehouse, before anyone asks for it

Change capture from Postgres to your warehouse with no schema coupling and no nightly window to miss. Supertype works with any Postgres instance out of the box.

Use Supertype's postgres service either way.

Metrics panel

Tabular figures wherever a value updates in place, proportional for the headline. The panel size rides the heading ladder, so these stats retune with the headings beside them.

This billing period
2.4M

events, across 40 workspaces

Rows synced

18,204

+12% vs last week

Lag

1.4s

p95, last hour

Slots

3

1 idle for 6 days

Pricing tiers

Each tier's feature list uses TypographyList variant="ui" to match the 13px card copy around it. The prose variant sets bullets at reading size, which would put two body sizes on one surface.

Pricing

Priced per source

No egress charges, no surprise invoice.

Solo
One database, one destination.
$0forever
  • 1 source
  • Daily sync
  • Community support
Choose Solo
Team
Everything a small data team needs.
$79per month
  • 10 sources
  • Streaming sync
  • Slack alerts
  • Audit log
Choose Team

Both tiers include the full connector set

Sources are counted by database, not by table.

Docs page

Steps, a callout, a prose list and an FAQ, all of it static. The FAQ uses Disclosure, which works before hydration. Switch to Accordion for animation or managed selection.

Guides

Getting data out of Postgres

Three approaches, ordered by how much of your schema they need to know. All of them assume a role with REPLICATION and a reachable host.

Set up a slot

Create the publication

One publication per destination. Naming it after the destination is what stops two syncs from quietly sharing a slot.

Create the replication slot

Slots are per-database, and the name has to be unique across the cluster.

Point the connector at it

The first read is a snapshot; everything after is the WAL stream.

Before you start

Replication slots hold WAL until they are consumed, and an abandoned slot fills the disk. See slot hygiene.

What you get

  • Row-level inserts, updates and deletes, in commit order.
  • Schema changes as DDL events, ahead of the rows using them.
  • A resumable position, so a restart picks up where it stopped.

Common questions

Does this lock the table?
The snapshot takes a brief ACCESS SHARE lock, leaving writes running.
What happens if the destination is down?
The slot holds the WAL and the connector resumes from its last position.
Can two syncs share a slot?
No. Each consumer advances the slot, so sharing one loses data for the other.

Next

Last reviewed March 2026

Article index

The meta row is what pulls /essay into a listing page. PostDate formats through formatPostDate, the same function to call when generating an OG image, so a card and its social preview print the same date.

Notes

Writing

An MDX article

Add to your configuration files and import the article shell. The article shell composes the essay pieces one by one, since its sections come from the markdown headings.

First the element map, a plain object. The router and the image component ship with the package, so it takes no arguments.

// mdx-components.tsx — the file convention @next/mdx calls with no arguments
import type { MDXComponents } from "mdx/types";
import { proseMdxComponents } from "@supertype.ai/foundations/mdx";

export function useMDXComponents(): MDXComponents {
  return proseMdxComponents as MDXComponents;
}

Then the code fences. rehypeProseCode writes --shiki-light and --shiki-dark onto every token in place of a fixed colour. One compiled document then serves both themes, with shiki.css selecting which applies.

// source.config.ts — runs in bare Node, so it must not reach React
import { rehypeProseCode } from "@supertype.ai/foundations/rehype";

export default defineConfig({
  mdxOptions: { rehypePlugins: [rehypeProseCode] },
});

Then the page around the compiled content.

// app/notes/[slug]/page.tsx — the article shell around compiled MDX
import { extractHeadings, readingTime, EssayHeader, ReadingLayout,
         PostMetaRow, PostDate, ReadTime, TagPills,
         MetaDot } from "@supertype.ai/foundations/essay";

const headings = extractHeadings(source);  // { id, label, depth }[]
const minutes = readingTime(source);        // words / 200, rounded up

<EssayHeader eyebrow="Notes" title={frontmatter.title} />
<ReadingLayout headings={headings}>
  <PostMetaRow>
    <PostDate date={frontmatter.date} format="long" />
    <MetaDot />
    <ReadTime minutes={minutes} />
    <MetaDot />
    <TagPills tags={frontmatter.tags} />
  </PostMetaRow>
  {content}
</ReadingLayout>

You can see an example of MDX-rendered content in the blog section of Viably (Observability-first work operating system), which also uses the @supertype.ai/foundations package for its design system.

Import rehypeProseCode from /rehype

source.config.ts runs in plain Node, where React fails to resolve. The plugin ships from its own entry point so that file can import it.