Switch from Neon

Both products give you PostgreSQL. The difference is underneath: Neon separates storage from compute and branches at the storage layer; CapyDB runs an ordinary PostgreSQL process on a dedicated storage dataset and clones the dataset to branch. The consequence you will feel is that a CapyDB cell behaves like the Postgres on your laptop, because it is one.

Your schema, your queries, your extensions, and your migrations move unchanged. What needs attention is the connection layer and anything written against a provider-specific driver.

• -Branching: preview databases are clones with a time to live, one per pull request
• -Scale to zero: an idle cell sleeps and wakes on the next connection, typically inside a quarter of a second
• -A pooled endpoint for serverless and edge runtimes, and a direct endpoint for everything else
• -Point-in-time restore, from continuous archiving rather than nightly snapshots
• -A platform integration for the deployment target you are already on

• -No HTTP or WebSocket driver: you connect over the PostgreSQL wire protocol, which every driver already speaks
• -Isolation is a whole process and a storage dataset per project, not a tenant inside a shared compute layer
• -Compute is a fixed CPU and memory ceiling per plan rather than autoscaling units
• -Standard cells have no outbound network access, so extensions that call out are unavailable by construction

If your project imports a Neon-specific serverless driver, the CLI rewrites it for you: the codemod swaps the client for a standard PostgreSQL driver, fixes the connection setup, and flags the call sites it could not decide about rather than guessing.

# Dry run by default - nothing is written until you say so
capydb migrate codemod neon
capydb migrate codemod neon --write

Start an import against your existing connection string. Follow mode keeps the new cell in sync with the source while you test, so the cutover is a DNS-and-environment-variable change rather than a maintenance window.

capydb import \
  --project my-app \
  --source-url "$OLD_DATABASE_URL" \
  --follow

• -Import with follow, and leave it running while you run your test suite against the cell
• -Run capydb doctor to catch environment variables still pointing at the old database
• -Swap the connection string in your deployment platform - the integration can do it per environment
• -Watch the logs and the connection count in the dashboard for the first few minutes
• -Stop the follow, then decommission the source once you are satisfied

For a production cutover, tell us before you start. We will review the plan, be present for the window, and keep a restore path ready. It costs you nothing and it is the difference between a boring evening and an interesting one.