# Limits and known gaps

> Status: Available. What pre-beta Gauntlet does not do. Read this before you rely on it.

## The ones that change how you use it

| Limit | What it means for you |
|---|---|
| No in-place upgrade to v1 | Plan to move data by backup and restore |
| Coordinated stop between beta builds | An upgrade is one outage. Never run two builds on one bucket prefix |
| Storage only grows | Budget the bucket for every write ever made, not for live rows. Dropping a database frees nothing |
| Backups are whole images | No point-in-time restore. Losing the bucket loses everything since the last finished backup |
| Commit latency follows the bucket | Each commit waits for conditional writes to the bucket. Put the bucket next to the nodes |
| One token per database, no roles | Anyone with the token can do everything in that database |
| One shard per new database | One database is limited to what one shard owner can serve |
| The bucket is trusted | Gauntlet does not encrypt or sign objects. Scope the bucket key to this bucket |
| No-wait locking | A conflicting transaction gets `40001` and must retry |
| `CREATE TABLE` only | No `ALTER`, `DROP` or `CREATE INDEX` |
| 128 PostgreSQL connections per node by default | One past the limit gets `FATAL 53300` |
| Memory budget is not an RSS ceiling | Size the host above `memory-mib` |
| Slow restart with the same node ID | A node restarted with the same `id` is not ready for 17–18 s |

## Not supported in pre-beta

| Area | Not available |
|---|---|
| Upgrades | No rolling upgrade and no mixed builds |
| Schema changes | No `ALTER`, `DROP` or `CREATE INDEX`. Indexes come only from `UNIQUE` at `CREATE TABLE` |
| SQL features | No savepoints, `COPY`, `SHOW <setting>`, query cancel, named parameters or schema-qualified names |
| Access control | No SQL roles or table privileges. No read-only or short-lived tokens |
| Storage | Nothing is reclaimed. The bucket only grows, even after a database is dropped |
| Recovery | No point-in-time restore. No branches |
| Scaling | One shard per new database. No shard split or move |
| Regions | One deployment, one single-region bucket. No region moves that keep the ID and token. No multi-region writes |
| Platforms | No macOS or Windows server binary. An aarch64 build exists but has not been run as a deployment |
| Clients | No certified ORM. No libSQL-compatible endpoint. No SDK, MCP server or agent skill |
| Service | No managed cloud, no public download, no SLA |

## Not yet verified

These are stated plainly so you do not assume more than has been shown.

- **The beta acceptance run has not passed.** The 48–72 hour run with node kills and a restore drill exists as a test driver.
- **No performance figure applies to the build you receive.** Latency figures the project has recorded come from earlier commits. Measure your own workload.
- **No failover time is guaranteed.**
- **No maximum database count has been qualified above 1,000.**
- **AWS S3, Google Cloud Storage and MinIO have no recorded run.** Only Tigris and Cloudflare R2 appear in the project's results.
- **node-postgres and pgjdbc over TLS** are documented, but the client suites run them on loopback without TLS.

## Where Gauntlet is behind

Product surface, by years: a table cannot change, an index exists only as `UNIQUE`, keys are not generated, no ORM is certified, nothing deletes, and there are no users or roles. Databases that acknowledge on local disks are faster per write than one that waits for a bucket. The [roadmap](https://gauntlet-db.stavros.xyz/docs/roadmap.md) is the plan to close the surface gap; an optional peer-durable mode is the answer to latency.

---
Source: https://gauntlet-db.stavros.xyz/docs/limits