Skip to main content

Using Sandboxes with Databases

Overview​

Signadot sandboxes are typically used alongside a shared database. While this shared model works well for most scenarios, teams sometimes need stronger isolation to avoid interference or when making schema changes. Signadot supports a "tunable isolation" approach so developers can choose the level of isolation appropriate for each workflow.

Shared Database with Partitioned Data​

By default, all sandboxes connect to the same database that backs the baseline environment. Tests can safely run against this database by partitioning data with identifiers such as an organization ID or user ID. Each sandbox operates on its own partition and should clean up its data when tests complete.

Temporary Databases for Schema Changes​

When tests involve database schema changes or require complete isolation, developers can spin up a temporary database instance:

  • Local Database – spin up a database locally on the developer workstation and route traffic to it using a sandbox with local mappings. This keeps the database entirely isolated yet behaves like any other sandbox in the cluster.
  • Resource Plugins – platform teams can automate ephemeral database creation using resource plugins. These plugins can spin up a lightweight database in any environment—either a container or a cloud service—often by creating a temporary schema that is deleted when the sandbox finishes. The plugin should also seed this database with any fixtures required by the tests.

Database Branching​

For databases that support branching, Signadot can automatically create an isolated database branch for each sandbox. This provides true full-stack isolation where every sandbox gets its own database branch that inherits all schema and data from the parent but operates independently. When the sandbox is deleted, the database branch is automatically cleaned up.

Neon Integration

See our Neon integration guide for a complete walkthrough of setting this up with Neon's copy-on-write database branching.

Choosing the Right Model​

Most teams start with the shared database model for convenience and use ephemeral databases only when necessary. Signadot's tunable isolation lets you mix these approaches so tests can run quickly by default while still enabling full isolation for edge cases and schema migration testing.

Native Integrations​

Signadot provides native integrations with popular database platforms to simplify ephemeral database provisioning: