# Adopting Coordinator DB

Evaluate Coordinator DB with a representative part of the application workload. Include the data types, transaction boundaries, result sizes and failure cases that the application will use after deployment.

## Define a useful trial

Choose a small dataset that contains realistic keys, missing values, duplicate input and boundary values. Create its schema explicitly, then run the application's writes and reads. Check the returned values and ordering as well as elapsed time.

Record which [deployment mode](https://coordinatordb.com/docs/get-started/about/deployment-modes) the application needs. A server connection is appropriate when several application processes share managed databases. An embedded connection is useful when the application owns the database file within its process.

## Check the integration contract

Use the supplied native client or the documented HTTP interface for a server trial. Check authentication, database selection, errors and output formats. Verify that transaction and temporary-table lifetimes match the application's request boundaries. HTTP request state ends with each request.

Test a failed write and a disconnected client. Confirm that retry logic cannot silently duplicate a mutation. Run a separate check for large result sets and inspect truncation or resource-limit errors before accepting the result.

## Record an adoption decision

Keep the schema, sample input, query commands, expected output and observations together. Include a database-copy procedure and a successful restore rehearsal. These artifacts let another person repeat the evaluation after a change.

For public case studies, use results and organization names that their owners have approved for publication. The [support report guide](https://coordinatordb.com/docs/resources/about/support) describes how to reduce a failing trial to a reproducible example. See [database copies](https://coordinatordb.com/docs/concepts/features/backup-restore/overview) for a supported recovery starting point.