# Does Logto Support Different Database Backends? PostgreSQL-Only Architecture Explained

> Logto exclusively supports PostgreSQL databases. Discover why this architecture is chosen and how it impacts your setup.

- Repository: [Logto/logto](https://github.com/logto-io/logto)
- Tags: deep-dive
- Published: 2026-07-06

---

**Logto currently supports only PostgreSQL as its database backend**, with all core persistence layers, migrations, and connection logic tightly coupled to PostgreSQL-specific drivers and schemas.

When evaluating Logto as an open-source identity and access management solution, understanding its database requirements is critical for infrastructure planning. According to the logto-io/logto source code, the platform is architecturally dependent on PostgreSQL, with no abstraction layers or alternative adapters available for other database systems.

## PostgreSQL-Specific Core Architecture

### OIDC Storage Adapter Implementation

The authentication layer relies on a PostgreSQL-specific implementation. In [`packages/core/src/oidc/adapter.ts`](https://github.com/logto-io/logto/blob/main/packages/core/src/oidc/adapter.ts), the `postgresAdapter` function constructs storage adapters for OIDC clients, tokens, and grants using PostgreSQL-native queries. There is no generic database interface or swappable adapter pattern—every persistence operation assumes a PostgreSQL backend.

### CLI Database Utilities

The command-line interface enforces PostgreSQL conventions. In [`packages/cli/src/database.ts`](https://github.com/logto-io/logto/blob/main/packages/cli/src/database.ts), the database utilities parse PostgreSQL DSN strings (`postgresql://...`) and automatically create a maintenance "postgres" database when provisioning new instances. The connection logic includes PostgreSQL-specific error handling and initialization sequences that cannot be redirected to other database engines.

### Container Orchestration and CI

Development and production environments standardize on PostgreSQL. The [`docker-compose.yml`](https://github.com/logto-io/logto/blob/main/docker-compose.yml) file spins up a `postgres:17-alpine` container and configures `DB_URL` with PostgreSQL protocol defaults. CI workflows and the [`.github/CONTRIBUTING.md`](https://github.com/logto-io/logto/blob/main/.github/CONTRIBUTING.md) documentation explicitly require contributors to have a PostgreSQL instance available, with no configuration options for alternative backends.

## Absence of Alternative Database Support

No MySQL, SQLite, or MongoDB adapters exist in the source tree. Unlike modular authentication systems that abstract database interactions through ORM layers or driver interfaces, Logto embeds PostgreSQL-specific type conversions in [`packages/schemas/src/gen/utils.ts`](https://github.com/logto-io/logto/blob/main/packages/schemas/src/gen/utils.ts) and relies on PostgreSQL features for schema generation and migrations. Attempting to connect to a non-PostgreSQL database results in connection failures and unsupported driver errors.

## Configuring Logto with PostgreSQL

Since Logto requires PostgreSQL, configuration focuses on PostgreSQL connection strings. Set the `DB_URL` environment variable to a valid PostgreSQL DSN before starting the application:

```bash
export DB_URL="postgres://postgres:yourPassword@localhost:5432/logto"
pnpm start:dev

```

Internally, the system instantiates the PostgreSQL adapter directly through the core package:

```typescript
import postgresAdapter from '#src/oidc/adapter.js';
const adapter = postgresAdapter(envSet, queries, 'Client');

```

This internal implementation in [`packages/core/src/oidc/adapter.ts`](https://github.com/logto-io/logto/blob/main/packages/core/src/oidc/adapter.ts) confirms that database interactions are hardcoded for PostgreSQL protocols.

## Summary

- Logto exclusively supports PostgreSQL as its database backend, with no abstraction layers for other databases.
- The OIDC storage layer in [`packages/core/src/oidc/adapter.ts`](https://github.com/logto-io/logto/blob/main/packages/core/src/oidc/adapter.ts) implements PostgreSQL-specific adapters without generic interfaces.
- CLI tools in [`packages/cli/src/database.ts`](https://github.com/logto-io/logto/blob/main/packages/cli/src/database.ts) assume PostgreSQL DSN formats and maintenance database conventions.
- Docker configurations deploy `postgres:17-alpine` containers, and documentation requires PostgreSQL for all development environments.
- Alternative databases such as MySQL, SQLite, or MongoDB are not supported in the current codebase.

## Frequently Asked Questions

### Can I use MySQL with Logto instead of PostgreSQL?

No, Logto does not support MySQL. The codebase lacks MySQL adapters or ORM abstraction layers that would translate between SQL dialects. All persistence logic in packages like [`packages/core/src/oidc/adapter.ts`](https://github.com/logto-io/logto/blob/main/packages/core/src/oidc/adapter.ts) uses PostgreSQL-specific syntax and connection handling.

### Does Logto support SQLite for development?

No, SQLite is not supported. While SQLite is often used for local development in other Node.js applications, Logto requires PostgreSQL features such as specific JSON handling and schema migration capabilities that SQLite does not provide. The CLI utilities explicitly expect PostgreSQL connection strings.

### Is there a MongoDB adapter for Logto?

No MongoDB adapter exists in the logto-io/logto repository. The storage architecture relies on relational SQL schemas and PostgreSQL-specific type conversions defined in [`packages/schemas/src/gen/utils.ts`](https://github.com/logto-io/logto/blob/main/packages/schemas/src/gen/utils.ts), making document-oriented databases incompatible without significant architectural changes.

### What PostgreSQL version does Logto require?

Logto development environments and CI pipelines use PostgreSQL 17 (specifically `postgres:17-alpine` as defined in [`docker-compose.yml`](https://github.com/logto-io/logto/blob/main/docker-compose.yml)). While earlier versions may function, the official support and testing targets PostgreSQL 17 for optimal compatibility with migration schemas and OIDC storage operations.