A realistic test database is not always a test-ready database.
A safe subset may contain the correct customers, orders, and payments, yet still lack the exact state needed by a test: an expired subscription, a pending refund, a locked account, or a feature flag enabled for one tenant.
Teams usually solve this with one-off seed scripts scattered across repositories and CI pipelines. Over time, those scripts drift, run in the wrong order, and become difficult to audit.
Ark Anchors™ make these scenario-specific changes reusable and deterministic.
What is an Anchor?
An Anchor is an idempotent SQL fixture managed by Ark. It applies a small, controlled delta to a prepared database so the environment starts in a known state.
An Anchor definition can include:
- PostgreSQL, MySQL, or generic SQL
- typed runtime parameters such as strings, dates, numbers, booleans, and enums
- default and required parameter values
- target database restrictions
- an execution order when several Anchors are selected
- tags and an active/inactive state for governance
Anchors can run after subsetting, after a test environment is provisioned, or on demand. This lets teams place the fixture at the correct point in the workflow instead of hiding it in an unrelated deployment script.
Why version pinning matters
When a job selects an Anchor, Ark records the requested version. Before execution, the control plane validates the definition, resolves its parameters, splits the SQL into statements, and builds an immutable execution plan.
If the Anchor changes while the job is waiting, Ark rejects the stale selection instead of silently running different SQL. The plan is also hashed, giving the run a stable identity for reproducibility and audit.
Execution results record which Anchor version ran, how many statements were applied, affected-row counts, duration, and success. SQL text and parameter values do not need to be exposed in job history.
What are Anchors useful for?
Common examples include:
- placing an order into a refundable state
- creating a known fraud-review case
- locking a user account for an authentication test
- enabling a tenant-specific feature flag
- setting dates around billing or renewal boundaries
- preparing the same clean demo scenario before every presentation
The important design rule is that an Anchor should be safe to run repeatedly. Idempotent statements keep retries and repeated environment creation predictable.
Anchors complement Business Objects
Anchors are not a replacement for relational subsetting.
Business Objects determine which domain records belong in the environment: the customer, their orders, related payments, and the relationships between them. Anchors then make focused changes to that prepared data.
The separation keeps both concerns understandable:
- Business Object: select the correct business context
- Anchor: establish the exact scenario state
That combination is useful for CI, QA, developer sandboxes, acceptance testing, and demos. Every environment can start with production-shaped relationships, protected sensitive data, and the same deterministic conditions the test suite expects.
The result is simpler than maintaining another folder of fragile seed scripts: define the scenario once, version it, parameterize it, and apply it through the same governed workflow that prepares the database.