Reference
Know what carries over—and what changes.
BaseCLF aims for familiar client workflows on Cloudflare infrastructure. Compatibility is practical, not a promise that D1 behaves like Postgres.
Capability matrix
| Capability | Status | Boundary |
|---|---|---|
| supabase-js query style | Supported | Same query grammar; the 14 operators SQLite cannot run are refused by name. |
| Email and password auth | Off by default | Hashing one password costs ~58 ms CPU against the free plan's 10 ms per request. |
| OAuth providers | Supported | Google and GitHub, configured per deployment. |
| Realtime subscriptions | Planned | No CDC on D1; change events would be produced by the Worker, not the database. |
| Postgres extensions | Not applicable | D1 is SQLite-based, not Postgres. |
| R2 object storage | Supported | Proxied through the Worker; no presigned URLs by design. |
How to read this page
- Supported means it runs on the shipped engine and is covered by its tests.
- Off by default means it exists and works; the default follows a measured cost, not a missing feature.
- Planned is roadmap language, not an available production feature.
- Not applicable is a property of SQLite rather than a gap.
Source of truth
These rows mirror the compatibility tables in the engine repository's README, which are maintained against its tests. The full tables list every refused operator and every place the client differs from supabase-js.