Data that knows its place.

01 / Keep three formats separate

Legacy NoqeriDB uses .nqd scripts and .nqdb files through noqeri db. The independently built native NoeSQL engine uses .noe schema/commands and .noedb storage. A .nqon manifest is data configuration, not a database. Never rename one format into another.

noqeri db tests/noqeridb.nqd build/legacy.nqdb
# The real native NoeSQL binary is selected by NOESQL_BIN:
noqeri sql --help

02 / NoeSQL bridge belongs to an external engine

The CLI forwards noqeri sql subcommands to a separately built native NoeSQL binary. A native web example uses database { engine: noesql } plus a query and db.execute; a working provider, schema, safe bindings and correct credentials are required. A unified typed compiler-to-NoeSQL query lowering pipeline is not complete.

database {
  engine: "noesql"
  path: "noqeri-data/visitors.noedb"
}
query visitors = "visitors get id, name sort id take 20"

03 / Optional SQL providers

Native web adapters are conditionally compiled for SQLite, PostgreSQL, DuckDB and MySQL/MariaDB when the relevant headers and libraries exist. CMake provider selection is not automatic proof of live cross-engine compatibility. Unknown adapters fail explicitly rather than silently falling back to a different store.

04 / Cloud database connections

Experimental server-side providers include Supabase PostgREST via libcurl, Firebase Realtime Database REST and Neon/PostgreSQL. Secrets belong in server environment variables; never expose privileged keys through browser view modules. Providers have distinct authorization and transport limits.

05 / Transactions, WAL and qualification

The repository also has JavaScript NoeSQL conformance/reference runtime code, SQLite/PostgreSQL translators and Noqeri-authored isolation/auth policy primitives. They are not a verified integrated ACID production engine. Durable WAL/fsync, multi-user policy, migrations, crash recovery and real provider E2E remain separate gates.