> Full Neon documentation index: https://neon.com/docs/llms.txt # Fast Dev Workflows Ship faster and safer with less manual work > Neon fundamentally accelerates our developer experience. It's a huge reason we are able to ship faster without worrying about breaking things > > — ben-vinegar, Co-founder at Modem ## Turn Postgres around: from bottleneck to accelerator **Startup teams today are not hiring dedicated DBAs.** Every engineer is busy building features and shipping quickly - they expect databases to adapt to their workflows, not the other way around. Most managed Postgres offerings on the market do not fit this model - except [Neon](https://neon.com/). - **No DBA-level knowledge needed.** Neon's [unique architecture](https://neon.com/docs/introduction/architecture-overview) removes the manual work traditionally associated with running Postgres: no provisioning, no resizing, no capacity planning, no optimizing large instances, no manually scaling storage, and no worrying about backups or restores. Even small, fast-moving teams can afford to run many databases and stay focused on shipping software. - **Branching workflows that match how you ship.** Instead of [forcing all developers into expensive, heavy shared dev instances](https://neon.com/branching/introduction), Neon lets you create [ephemeral, lightweight branches](https://neon.com/branching/rethinking-the-database) in seconds for development, testing, and CI/CD - just like you do with code. When you are done, you (or a script, automation, or API call) delete them. All environments stay in sync with production without manual work or coordination. ## Neon does the boring DBA work so you do not have to ![Neon autoscaling adjusts compute based on workload demand](https://neon.com/use-cases/fast-dev-workflows/autoscaling-based-on-demand.png) Neon's serverless architecture takes care of the database tasks that typically eat up time on small teams: ### Automatic provisioning vs. manual capacity planning With Neon, there is no need to provision instances, size disks, or plan for future growth. Compute and storage are managed automatically. You do not have to think about which instance size you need today or how you will scale it six months from now. ### Autoscaling vs. overprovisioning for "just in case" traffic Instead of forcing you to overprovision compute instances to cover sporadic traffic spikes, [Neon automatically scales compute between a minimum and maximum based on demand](https://neon.com/docs/introduction/autoscaling). You get protection against unexpectedly high load without manually resizing databases or pre-provisioning excess capacity, and you only pay when your database actually needs it. When demand drops, compute scales back down quickly. **Tip:** Read our [Autoscaling Report](https://neon.com/autoscaling-report) for data on the effects of Neon's autoscaling across thousands of production workloads. ### Scale to zero vs. paying for inactive environments Development, preview, and test databases do not need to run 24/7 - and you should not be paying for them either. In Neon, [non-production databases scale to zero when idle](https://neon.com/docs/introduction/scale-to-zero). Teams do not pay for environments that are not actively in use, and they do not need to manually pause, resume, or clean them up. ### APIs and automation vs. manual database ops All of this is exposed through a simple, intuitive API that works with the tools developers already use. Neon is compatible with all major frameworks and ORMs, and because it is still Postgres, there is no new database model to learn. ## Remove friction with branching workflows > With Neon, we found a way to scale our setup more efficiently, using branching instead of duplicating instances and autoscaling to match our actual load. > > — thorsten-riess, Software Architect at traconiq If Neon's serverless architecture is the foundation that enables speed, Neon branches are the magic trick that takes it to the next level. Built on Neon's copy-on-write architecture, branches are: - **Created instantly** - no matter how much data you have - **Exact copies of production** - schema and data - **Fully API-friendly** - built for automation - **Affordable by default** - they do not duplicate storage and do not consume compute while inactive Branches turn the database into a resource you can create, use, and throw away as part of your normal development flow. ![Neon branching workflow for isolated environments](https://neon.com/use-cases/fast-dev-workflows/neon-branching-workflow-overview.png) ### Using branches as environments In traditional managed Postgres setups, you'd be running separate database instances for staging, dev, and testing, then manually configuring them and constantly trying to keep them "close enough" to production. That work never really ends. In Neon, a new branch is an isolated environment - one that already contains your full production history, schema, and configuration. You start from production, deploy a branch instantly, and move on. > The services that touched schema changes or write-heavy paths could never share a database safely. Now every sandbox gets its own isolated Postgres DB whenever required > > — joe-horsnell, Principal Platform Engineer at Bitso ### Staging that resyncs with production in one API call In Neon, staging is just a branch derived from production. When production changes, you do not need to rebuild staging from scratch or run complex sync jobs. You can reset your staging branch from production in a single API call, instantly bringing schema and data back in sync. This makes staging a reliable checkpoint instead of a slowly drifting approximation, and removes a whole class of "works in staging but not in prod" issues. ![Reset staging from production with a single API call](https://neon.com/use-cases/fast-dev-workflows/staging-resync-from-production-api.png) [Read more about using branches for staging](https://neon.com/branching/production-staging-workflows) ### Dev environments for every developer, PR, or experiment Branches make it practical to give every developer - and every PR - its own database environment. Each environment is isolated, production-like, and safe to break. Developers can test migrations, schema changes, and data-heavy features without coordinating with each other or worrying about corrupting shared state. ![Per-developer and per-PR isolated database branches](https://neon.com/use-cases/fast-dev-workflows/per-developer-and-pr-database-branches.png) [Read more about using branches for development](https://neon.com/branching/branching-workflows-for-development) ### Promote from dev to prod safely, even with many parallel environments As teams scale, promotion becomes harder. Multiple developers, multiple branches, multiple schema changes - all converging on production. Neon supports promotion workflows built on branching and snapshots. Teams can validate changes in isolated branches, promote them intentionally, and keep a rollback point ready in case something goes wrong. ![Promote validated changes from development to production safely](https://neon.com/use-cases/fast-dev-workflows/instant-recovery-with-branches-and-snapshots.png) [Read more about building promotion workflows with Neon](https://neon.com/branching/advanced-branching-workflows) ### Let automation take over All of these workflows are designed to be automated from day one: - Branches can be [created automatically for PRs](https://neon.com/docs/guides/neon-github-integration) - [Preview deployments connect to their own Neon branches](https://neon.com/docs/guides/vercel-overview) so application code and database state stay aligned throughout the review process - [Branches are deleted automatically](https://neon.com/docs/guides/branch-expiration) when they are no longer needed - Everything is [fully programmable via API](https://neon.com/docs/reference/api-reference) - Neon works with AI IDEs and coding agents with tools like [MCP](https://neon.com/docs/ai/neon-mcp-server), [neon init](https://neon.com/docs/reference/cli-init), and Neon [skills](https://neon.com/docs/ai/ai-rules) > Time to launch is crucial for us: when we tried Neon and saw that spinning up a new branch takes seconds, we were blown away > > — alex-co, Head of Platform Engineering at Mindvalley ## Build without fear with instant recovery built-in Moving fast means mistakes happen - a bad migration, a dropped column. Neon is built so recovery is not an emergency procedure but part of the normal workflow. ![Instant recovery using Neon branches and snapshots](https://neon.com/use-cases/fast-dev-workflows/safe-promotion-workflow-dev-to-prod.png) - **Branching and snapshots instead of dump-and-restore panic.** Traditional recovery means finding the right backup, restoring it somewhere, repointing apps, hoping nothing else breaks in the process. With Neon, recovery is built on the same primitives you already use for development: branches and snapshots. You can create a snapshot of a branch at any point in time, and restore from it instantly. - **Fix mistakes in seconds, not hours.** Because restores are instant, teams do not have to choose between speed and safety. - **Everything is API-driven.** Restores can be scripted, automated, or integrated into existing workflows just like branching and CI. > I caught a broken migration thanks to a Neon branch that mirrored production. That bug would have made it to prod in any other setup > > — oliver-stenbom, Co-founder at Endform ## Fast dev workflows for agents, too AI agents do not want long-lived infrastructure - they want databases they can spin up instantly, use while a task is running, and shut down when they are done. Neon's model maps cleanly to that way of working. That is why Neon is the Postgres of choice for [agentic platforms](https://neon.com/case-studies#ai) and why we're even offering a [dedicated Agent Plan](https://neon.com/programs/agents#agent-plan-pricing) designed for these workloads. ![Agent-friendly database lifecycle with Neon](https://neon.com/use-cases/fast-dev-workflows/agent-database-lifecycle-workflow.png) > Neon turns a database into something an agent can actually use. Spin it up, load data, reason over it, shut it down when the task is done. That is exactly how agents want to work > > — rick-blalock, Co-founder at Agentuity What makes Neon so fitting for agents: - **Postgres that agents can deploy and manage.** With Neon, agents can provision Postgres databases programmatically via API, without manual sizing, capacity planning, or configuration work. - **Large fleets != large costs.** Those same databases scale down to zero when inactive, so deploying thousands of rarely used databases does not become a cost concern. - **Branches for checkpoints and versions.** Agents can use branches and snapshots to maintain versioned states of an app or workflow, or to offer restore and rollback features directly to end users. - **A full backend via SDKs.** For full-stack agents, Neon also provides [Auth](https://neon.com/docs/auth/overview) and PostgREST-compatible APIs, packaged together in a single SDK. [Keep reading](https://neon.com/use-cases/ai-agents) > Fimo lets teams experiment without fear because you can always roll back. Neon's branches and snapshots are what make that possible > > — pierre-burgy, CEO at Strapi ## Get started Fast teams should not be slowed down by heavyweight database workflows. Neon removes the manual work and risk that usually come with running Postgres while keeping everything production-ready. - **With usage-based pricing,** no long-term commitments. [See our pricing](https://neon.com/pricing) - **Meets your standards for security and compliance.** [Backed by Databricks](https://neon.com/security) - **Trusted by teams deploying tens of thousands of databases every day.** [Explore case studies](https://neon.com/case-studies) [**Sign up in seconds and start building.**](https://console.neon.tech/signup) If you are just getting started, check out the [Neon Startup Program](https://neon.com/startups) for extra support as you grow.