rasterizeddb_server-PLATFORM-x64.exe --location /your-location/bla-bla --concurrent_threads 16 --batch_size 16000
The server can also speak the PostgreSQL v3 wire protocol ("pgwire") so that tools like psql can connect.
- Start the server in pgwire mode (trust auth, no SSL):
cargo run -p rasterizeddb_core -- --location <PATH> --protocol pgwire --pg-addr 127.0.0.1 --pg-port 5432
- Connect with psql:
psql "sslmode=require host=127.0.0.1 port=5432 user=any dbname=any"
Notes:
- This is a network-level Postgres simulation: it supports the startup/auth flow and simple queries, and forwards supported SQL (CREATE/INSERT/SELECT) into RasterizedDB’s current SQL parser/executor.
- TLS is enabled by default in pgwire mode (self-signed cert unless
--pg-cert/--pg-keyare provided). - The extended query protocol (prepared statements) is not implemented yet.
batch_size: recommended value is 16K, but you can play around with more or less depending on your case. The lesser the number of rows, the lower the batch size must be. concurrent_threads: must equal to the number of CPU threads of lower.
Refer to test_client/src/main.rs for examples!
Rasterized DB has recently undergone a complete rewrite from the ground up and is still in an active state of redevelopment. This major overhaul has brought significant architectural changes to improve stability, performance, and developer experience. Many components are being redesigned for long-term maintainability, and the database will continue to evolve rapidly until its core design reaches maturity.
Originally conceived as a schemaless database, Rasterized DB is now schema-full. The database itself now manages and enforces the schema, reducing complexity for client applications and enabling stronger data consistency. This change also opens the door to richer query capabilities and deeper optimizations at the storage and execution layers.
To make adoption easier, Rasterized DB aims for compatibility with the PostgreSQL SQL dialect, the most widely used and supported SQL standard in production environments. While not all PostgreSQL features are currently implemented, this compatibility goal ensures developers can leverage familiar syntax and tools without learning a proprietary query language from scratch.
Rasterized DB takes inspiration from how the web handles caching. Just like a browser reuses files when their cache headers indicate they’re still valid, Rasterized DB hashes each query so repeated requests can instantly fetch results from a known storage offset without rescanning the dataset.
Future updates will introduce in-memory row caching, allowing certain queries to bypass disk entirely. This approach will merge the speed of in-memory stores like Redis with the persistence of a traditional database.
Rust combines zero-cost abstractions with low-level performance control, making it ideal for building a database that is both fast and safe. Its memory safety guarantees reduce the risk of crashes or data corruption, while still enabling optimizations close to the hardware.
Rasterized DB is designed to handle virtually unlimited data sizes, row counts, and column counts. Planned features include:
- Advanced data types: arrays, vectors, tensors, and more
- Row insertion, updates, and deletions via SQL
- Vacuuming unused space
- UUID (GUID) support
- Fully functional RETURN, LIMIT, and advanced SELECT capabilities
- Server mode with network access
- Sharding for horizontal scalability
- Compression for storage efficiency
- Table immutability options
An official Rust ORM is in development, with a C# ORM planned afterward. These tools will provide a seamless experience when integrating Rasterized DB into applications.
Currently, Rasterized DB is not stable. Table formats, storage engines, and query processing internals are likely to change until version 1.0.0. Use it at your own risk in production environments.
// COMING SOON
// Please refer to the main.rs and core/mock_table.rs and core/mock_helpers.rs to see API in use.
Everything in this directory is distributed under GNU GENERAL PUBLIC LICENSE version 3.