morishuz/CoreSQL

A small, extensible experimental embedded database in C++20

C++

0

1 commits

updated Sep 16, 2026

See the code
cpp
cpp20
database
database-engine
database-extension
embedded-database
in-memory-database
sql

README

CoreSQL

CoreSQL logo

A small, extensible embedded database in C++20.

CoreSQL explores a simple idea: a database should be small enough to understand and structured enough to extend. It combines a typed relational core, optional SQL, and durable local files. It has no SQLite runtime dependency.

  • Small and readable. About 10,000 lines across the engine, SQL frontend, public headers and bundled add-ons, including comments and blank lines; tests and external reference code are separate.
  • Clear boundaries. Storage and transactions belong to the core. SQL parsing and domain-specific behavior live in separate modules.
  • Extensible by design. Register types, scalar functions, aggregates and index providers. Even built-in integer, real and text types use the type-extension API. Bundled add-ons include JSON, vectors, dates, decimals, timestamps, spatial boxes and an experimental graph API.

Extensions are trusted, linked C++ code, not sandboxed or dynamically loaded plugins. The storage engine, transaction model and query operators remain part of the core. See the extension contract.

Status: early and experimental

0.1.0 is in development. CoreSQL is useful for experimentation and small local applications whose owners can accept changing interfaces and maintain backups. It is not yet a production replacement for SQLite or DuckDB.

Transactions, savepoints, indexes, crash recovery, backup/restore and a bounded SQL dialect are implemented. API/ABI and permanent file compatibility are not promised. All live data stays in RAM; the default encoded-state limit is 1 GiB, configurable at build time, not a RAM budget. A file has one owner, and calls require external serialization. Windows, a server protocol and full SQL compatibility are absent.

Read the SQL dialect, storage contract and backup/upgrade guide before keeping data you care about.

Try it

Requires CMake 3.20+, a C++20 toolchain with floating-point from_chars/to_chars, and macOS 26+ or Linux. Python 3.9+ enables the full test suite.

cmake -S . -B build/release -DCMAKE_BUILD_TYPE=Release
cmake --build build/release -j 4
ctest --test-dir build/release --output-on-failure -j 4
./build/release/coresql_persistent_sql notes.core
./build/release/coresql_sql_cli examples/sql.sql

The persistent example writes, closes and reopens its database. The CLI runs SQL scripts or reads standard input. Ordinary builds fetch no dependencies. For C++ integration, use CoreSQL::core or CoreSQL::sql through CMake; installation and examples cover the complete workflow.

Performance

The latest recorded full TPC-H Q1–Q22 comparison is a historical September 15, 2026 run at SF 0.03 (180,566 lineitems). CoreSQL completed and checked all 22 queries. SQLite completed 20: CoreSQL was faster on 12, SQLite on eight; SQLite hit the 15-second timeout on Q19 and Q21. DuckDB was faster on all 22 in that run.

These are single-thread, in-memory client timings on an Apple M1 with 16 GiB RAM: median of three measured runs after one warmup, excluding loading. Parsing, execution and fetching are included. SQLite uses adapted SQL, TEXT dates and approximate REAL decimals; CoreSQL uses native DATE/DECIMAL. Drivers also differ. This is an engineering comparison, not an official TPC-H result, a durability benchmark, or evidence of general superiority.

All 22 query times — milliseconds, lower is better
QueryCoreSQL msSQLite ms
Q1175.28390.511
Q221.43719.803
Q332.46448.350
Q419.69037.819
Q539.43670.774
Q629.70211.726
Q764.95756.954
Q834.362129.663
Q957.243158.060
Q1024.92718.897
Q115.36025.208
Q1230.58823.301
Q1338.57446.479
Q1420.04911.768
Q1520.17711.745
Q168.20610.973
Q1713.022801.836
Q1862.45475.183
Q1914.256Timeout (>15 s)
Q2013.2011251.266
Q21600.516Timeout (>15 s)
Q228.364336.354

No speed ratio is assigned to timeouts. SQLite is the pinned 3.54.0 development baseline, not a stable-release comparison. CoreSQL was a modified working tree based on 2d3342712b; these measurements predate the current changes and are not a benchmark of the current checkout. Three trials do not establish a stable ranking for close results; Q8 also showed variability in a separate check.

Full methodology and DuckDB results · Raw measurements and fingerprints · Reproduction instructions

Explore and contribute

Guide · Examples · Architecture · Documentation · Contributing · Release readiness

CoreSQL's original contributions use the MIT license. External material retains its own notices. CoreSQL is independently maintained and is not affiliated with SQLite or DuckDB. The original development and SQLite reference history is preserved separately from the single-commit main branch; see provenance and third-party notices.

Contributors

morishuz

1 commits

morishuz/CoreSQL

A small, extensible experimental embedded database in C++20

C++

0

1 commits

updated Sep 16, 2026

See the code
cpp
cpp20
database
database-engine
database-extension
embedded-database
in-memory-database
sql

README

CoreSQL

CoreSQL logo

A small, extensible embedded database in C++20.

CoreSQL explores a simple idea: a database should be small enough to understand and structured enough to extend. It combines a typed relational core, optional SQL, and durable local files. It has no SQLite runtime dependency.

  • Small and readable. About 10,000 lines across the engine, SQL frontend, public headers and bundled add-ons, including comments and blank lines; tests and external reference code are separate.
  • Clear boundaries. Storage and transactions belong to the core. SQL parsing and domain-specific behavior live in separate modules.
  • Extensible by design. Register types, scalar functions, aggregates and index providers. Even built-in integer, real and text types use the type-extension API. Bundled add-ons include JSON, vectors, dates, decimals, timestamps, spatial boxes and an experimental graph API.

Extensions are trusted, linked C++ code, not sandboxed or dynamically loaded plugins. The storage engine, transaction model and query operators remain part of the core. See the extension contract.

Status: early and experimental

0.1.0 is in development. CoreSQL is useful for experimentation and small local applications whose owners can accept changing interfaces and maintain backups. It is not yet a production replacement for SQLite or DuckDB.

Transactions, savepoints, indexes, crash recovery, backup/restore and a bounded SQL dialect are implemented. API/ABI and permanent file compatibility are not promised. All live data stays in RAM; the default encoded-state limit is 1 GiB, configurable at build time, not a RAM budget. A file has one owner, and calls require external serialization. Windows, a server protocol and full SQL compatibility are absent.

Read the SQL dialect, storage contract and backup/upgrade guide before keeping data you care about.

Try it

Requires CMake 3.20+, a C++20 toolchain with floating-point from_chars/to_chars, and macOS 26+ or Linux. Python 3.9+ enables the full test suite.

cmake -S . -B build/release -DCMAKE_BUILD_TYPE=Release
cmake --build build/release -j 4
ctest --test-dir build/release --output-on-failure -j 4
./build/release/coresql_persistent_sql notes.core
./build/release/coresql_sql_cli examples/sql.sql

The persistent example writes, closes and reopens its database. The CLI runs SQL scripts or reads standard input. Ordinary builds fetch no dependencies. For C++ integration, use CoreSQL::core or CoreSQL::sql through CMake; installation and examples cover the complete workflow.

Performance

The latest recorded full TPC-H Q1–Q22 comparison is a historical September 15, 2026 run at SF 0.03 (180,566 lineitems). CoreSQL completed and checked all 22 queries. SQLite completed 20: CoreSQL was faster on 12, SQLite on eight; SQLite hit the 15-second timeout on Q19 and Q21. DuckDB was faster on all 22 in that run.

These are single-thread, in-memory client timings on an Apple M1 with 16 GiB RAM: median of three measured runs after one warmup, excluding loading. Parsing, execution and fetching are included. SQLite uses adapted SQL, TEXT dates and approximate REAL decimals; CoreSQL uses native DATE/DECIMAL. Drivers also differ. This is an engineering comparison, not an official TPC-H result, a durability benchmark, or evidence of general superiority.

All 22 query times — milliseconds, lower is better
QueryCoreSQL msSQLite ms
Q1175.28390.511
Q221.43719.803
Q332.46448.350
Q419.69037.819
Q539.43670.774
Q629.70211.726
Q764.95756.954
Q834.362129.663
Q957.243158.060
Q1024.92718.897
Q115.36025.208
Q1230.58823.301
Q1338.57446.479
Q1420.04911.768
Q1520.17711.745
Q168.20610.973
Q1713.022801.836
Q1862.45475.183
Q1914.256Timeout (>15 s)
Q2013.2011251.266
Q21600.516Timeout (>15 s)
Q228.364336.354

No speed ratio is assigned to timeouts. SQLite is the pinned 3.54.0 development baseline, not a stable-release comparison. CoreSQL was a modified working tree based on 2d3342712b; these measurements predate the current changes and are not a benchmark of the current checkout. Three trials do not establish a stable ranking for close results; Q8 also showed variability in a separate check.

Full methodology and DuckDB results · Raw measurements and fingerprints · Reproduction instructions

Explore and contribute

Guide · Examples · Architecture · Documentation · Contributing · Release readiness

CoreSQL's original contributions use the MIT license. External material retains its own notices. CoreSQL is independently maintained and is not affiliated with SQLite or DuckDB. The original development and SQLite reference history is preserved separately from the single-commit main branch; see provenance and third-party notices.

Contributors

morishuz

1 commits

Languages

C++

86.0%

Python

11.5%

CMake

2.4%