> For the complete documentation index, see [llms.txt](https://docs.prestd.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prestd.com/databases/roadmap.md).

# Database roadmap

This page describes **planned** SQL adapters for pREST. Nothing here is installable until a release ships it. PostgreSQL is native today — see [Databases](/databases.md).

*Last updated: July 18, 2026*

***

## Why this order?

Developer usage (for example Stack Overflow surveys) weights **PostgreSQL, MySQL, SQLite, and SQL Server** heavily for application builders. Broader market-visibility rankings put Oracle and warehouses higher, but they are a poorer early fit for open-source adoption per engineering hour.

pREST therefore prioritizes:

1. Certify the **PostgreSQL-compatible** family on the existing adapter
2. **MySQL family** (high SEO + open-source fit)
3. **SQLite** (local/file DX)
4. **SQL Server / Azure SQL** (enterprise)
5. **Oracle** or **analytical read-only** based on demand

***

## Adapter families (target)

```
PostgreSQL family — native today
├── PostgreSQL
├── CockroachDB (certify)
├── YugabyteDB (certify)
└── Aurora PostgreSQL (certify)

MySQL family — Phase 2
├── MySQL, MariaDB (dialect profiles)
├── TiDB, Aurora MySQL (certify after MySQL adapter)

Embedded family — Phase 3
└── SQLite

SQL Server family — Phase 4
├── SQL Server
└── Azure SQL

Later / separate
├── Oracle (Phase 5)
└── Analytical read-only: DuckDB, ClickHouse, Snowflake, BigQuery
```

***

## Phases

| Phase | Focus                                                                                                                                                                                                                                                          | Status          |
| ----- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| **1** | Certify CockroachDB, YugabyteDB, Aurora PostgreSQL; Timescale E2E ([v2.2.0](/releases/v2.2.0.md) / [#988](https://github.com/prest/prest/pull/988)); Timescale adapter + multi-adapter routing on **`main`** ([#999](https://github.com/prest/prest/pull/999)) | **In progress** |
| **2** | MySQL/MariaDB native dialect; certify TiDB + Aurora MySQL                                                                                                                                                                                                      | Roadmap         |
| **3** | SQLite native — one file → REST/MCP                                                                                                                                                                                                                            | Roadmap         |
| **4** | SQL Server + Azure SQL                                                                                                                                                                                                                                         | Roadmap         |
| **5** | Oracle vs analytical read-only track                                                                                                                                                                                                                           | Undecided       |

Current support labels: [Databases](/databases.md).

***

## Analytical databases (separate track)

Snowflake, Databricks, BigQuery, ClickHouse, and DuckDB speak SQL but are a poor fit for generic transactional CRUD (`POST`/`PATCH`, row updates, transactions).

Planned direction:

```
adapter mode: transactional
adapter mode: analytical-read-only
```

Analytical mode would emphasize schema exploration, controlled queries, scripts, and MCP — not forced row-level CRUD.

***

## Architecture direction

Future adapters should isolate **SQL generation and schema behavior**, not only connection drivers. Design direction (not yet implemented in this docs pass):

* Explicit `Dialect` / `Capabilities` interfaces
* Shared contract-test suite (discovery, CRUD, pagination, JSON, MCP, ACL)
* Separate modules where practical (`prest-adapter-postgres`, `prest-adapter-mysql`, …)

***

## Related

* [Databases](/databases.md)
* [Homepage](/readme.md)
* [Key features](/readme/prestd-key-features.md)