Exploration: Support for Pluggable Database Backends or Custom On-Disk Format

### Exploration: Support for Pluggable Database Backends or Custom On-Disk Format

Currently, PebbleVault only supports SQLite via the existing ORM layer.
It would be valuable to explore adding support for alternative database backends (e.g., PostgreSQL, MySQL) or even building a custom on-disk format optimized for spatial queries and fast inserts.

This could take the form of:

- A trait-based abstraction over the persistence layer
- Feature flags to opt into specific backends
- Benchmarks comparing SQLite vs alternatives
- Potential exploration of a custom format tailored to spatial use cases

#### Motivation

- Benchmark and compare different storage engines
- Prepare for future scale
- Evaluate tradeoffs between general-purpose DBs vs a domain-specific format
- Unlock potential integrations for teams already using other DBs
- Help inform future architectural decisions for Horizon or any downstream consumers

#### Initial Steps

- Audit current ORM usage for database-specific dependencies
- Define abstraction boundary for pluggable backends
- Prototype one alternative backend (e.g., PostgreSQL or a minimal binary format)
- Benchmark common operations (inserts, spatial queries, region loading) against SQLite

---

### 🚨 Naming Clarification Vote

The current module is named `MySQLGeo`:

```rust
//! MySQLGeo: A module for persistent storage of spatial data.
//!
//! This module provides a `Database` struct for interacting with a SQLite database
//! to store and retrieve spatial data points. It also handles file-based storage
//! for larger data objects associated with each point.
```
However, it **does not support MySQL**. To avoid confusion and better reflect its function, consider renaming it to something more accurate, such as:

**✅ Proposed name:** `SpatialStore`

**Other alternatives:**
- `GeoStore`
- `SpatialDB`
- `VaultStore`
- `SQLiteGeo` (if remaining SQLite-specific)

Cast a vote or suggest a better name if you'd like!