Skip to main content

Set up Data Isolation

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 local sandbox. 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.

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.