# Integrate an application with Coordinator DB

Choose an integration by where the application runs and how long its connection state must live. The documented public options are native TCP, HTTP and an embedded connection API. Do not assume a driver or compatibility protocol exists merely because another database offers one.

Native connections are stateful. They retain the selected database, transactions and temporary tables, and the supplied client supports interactive queries, scripted output and local file input. HTTP accepts authenticated SQL requests and returns registered formats; each request has its own session.

```sh
curl --silent --user default: --data-binary 'SELECT 1 FORMAT csv' \
  'http://127.0.0.1:7401/?database=data'
```

This command uses the local sample account. Use the credentials and secure connectivity intended for the actual application. An embedded application opens its database directly and can use prepared bindings; server commands and format encoders are not part of that connection's interface.

For data exchange, choose an input or output format based on the values that must be preserved. Validate NULL handling, exact numeric types and repeated-request behavior before sending real data. Several applications should connect to one server instead of opening the same file independently.

See [deployment modes](https://coordinatordb.com/docs/get-started/about/deployment-modes), [native client](https://coordinatordb.com/docs/concepts/features/interfaces/client), [HTTP](https://coordinatordb.com/docs/concepts/features/interfaces/http) and [formats](https://coordinatordb.com/docs/reference/formats).