# Public connection model

An application chooses between a server connection and an embedded connection. This choice defines who owns session state and how several application instances reach the database.

## Server connections

Native TCP and HTTP reach the same server-managed database inventory and configured users. A [native connection](https://coordinatordb.com/docs/concepts/features/interfaces/tcp) authenticates once and retains its selected database, temporary objects and transaction until disconnection. Closing it rolls back uncommitted work.

An [HTTP request](https://coordinatordb.com/docs/concepts/features/interfaces/http) owns a separate session. Select the database for each request. Put all statements that share a transaction or temporary table into that request; an open transaction is rolled back before the response is delivered.

## Embedded connections

An embedded connection opens a file or an in-memory database directly. It offers typed results and [prepared statements](https://coordinatordb.com/docs/guides/clickhouse/data-modelling/stored-procedures-and-prepared-statements). Server commands such as `USE`, `SHOW` and `SET` are outside that API.

Multiple connections in one process can share a database file. Simultaneous access to the same file from separate processes is outside the supported concurrency model. Applications running in several processes should connect to one server. Choose and document this boundary before adding connection pooling or background jobs; see [deployment modes](https://coordinatordb.com/docs/get-started/about/deployment-modes).