This document outlines potential features that could enhance pgsqlite by working within SQLite's constraints to provide better PostgreSQL compatibility and performance.
SQLite only allows one writer at a time, causing "database locked" errors for concurrent writes.
- Queue concurrent write requests instead of failing immediately
- Batch multiple writes together in single transactions
- Configurable batch size and time windows (e.g., batch up to 100 writes or 10ms)
- Priority queuing for critical writes
- Return PostgreSQL-compatible transaction IDs immediately
- Dramatically improved concurrent write performance
- Better user experience (no immediate failures)
- Optimal use of SQLite's write capabilities
PostgreSQL supports multiple databases per server instance, SQLite doesn't.
- Support
CREATE DATABASE/DROP DATABASEcommands - Map each database name to a separate SQLite file
- Route connections based on database parameter
- Maintain a registry of databases in a metadata SQLite file
- Support PostgreSQL's
\lcommand to list databases
- True multi-tenant isolation
- Easy per-database backups
- Compatible with PostgreSQL tooling expectations
- Simple database cloning (just copy the file)
SQLite's single-writer limitation affects read scalability under write load.
- Maintain read-only copies using SQLite's backup API
- Route SELECT queries to replicas, writes to primary
- Configurable replication lag tolerance
- Automatic replica promotion on primary failure
- Load balancing across multiple replicas
- Horizontal read scaling
- Zero-downtime backups from replicas
- Improved read performance during writes
- High availability option
Current connection handling doesn't optimize for SQLite's characteristics.
- Separate read and write connection pools
- Fair queuing for write operations with timeouts
- Connection priorities and weights
- Automatic retry with exponential backoff
- Pre-warmed connections with cached metadata
- Configurable max wait times
- Better resource utilization
- Improved fairness under load
- Reduced connection overhead
- Better error handling
No built-in way to query historical data in SQLite.
- Leverage SQLite's WAL for historical queries
- Support:
SELECT * FROM users AS OF TIMESTAMP '2024-01-01' - Configurable retention periods
- Automatic old WAL cleanup
- Optional separate history database
- Powerful debugging capabilities
- Audit trail functionality
- Undo capabilities for applications
- Compliance with data retention requirements
Large tables can exceed SQLite's practical size limits.
- Transparent sharding across multiple SQLite files
- Hash or range-based partitioning
- Parallel query execution across shards
- Automatic shard rebalancing
- Shard-aware query optimization
- Overcome SQLite size limitations
- Better performance for large datasets
- Parallel query execution
- Easier maintenance of large tables
Limited visibility into pgsqlite's operation and performance.
- Prometheus metrics endpoint
- Built-in query performance tracking
- Lock contention monitoring
- Slow query log with explain plans
- Database growth tracking
- Connection pool statistics
- Cache hit rate metrics
- Production-ready monitoring
- Performance troubleshooting
- Capacity planning data
- SLA monitoring
No easy way to manage SQLite-specific features through PostgreSQL protocol.
- Web-based admin interface at
/admin - PRAGMA configuration management
- Automatic VACUUM scheduling
- Index usage statistics
- Visual query plan analysis
- Live performance metrics
- Database file management
- Easy SQLite administration
- Visual performance tuning
- Reduced operational overhead
- Better debugging tools
No native way to stream changes from SQLite.
- Trigger-based change capture
- Stream to Kafka/Redis/webhooks
- Debezium-compatible format
- Configurable filters and transformations
- At-least-once delivery guarantees
- Change buffering during downstream outages
- Enable event-driven architectures
- Real-time cache invalidation
- Data pipeline integration
- Audit logging
All queries treated equally regardless of characteristics.
- Automatic read/write query detection
- Route analytical queries to replicas
- Custom routing rules via configuration
- Query pattern learning
- Automatic index recommendations
- Query result pre-computation
- Better resource utilization
- Improved query performance
- Reduced primary database load
- Self-tuning capabilities
Limited backup options for production use.
- Continuous incremental backups
- Point-in-time recovery (PITR)
- Backup to S3/cloud storage
- Parallel backup streams
- Backup verification and testing
- One-command disaster recovery
- Cross-region replication
- Production-grade data protection
- Compliance with backup requirements
- Minimal performance impact
- Quick recovery options
Large result sets consume excessive memory.
- True cursor support with
DECLARE CURSOR - Streaming result sets
- Configurable fetch sizes
- Automatic pagination
- Memory-limited result buffering
- Async result streaming
- Handle arbitrary large results
- Reduced memory usage
- Better performance for exports
- PostgreSQL cursor compatibility
- Write Queue & Batching - Immediate performance benefit
- Multi-Database Router - Enables many use cases
- Connection Management - Better concurrency handling
- Read Replicas - Horizontal scaling
- Monitoring/Metrics - Production readiness
- Backup & Recovery - Data safety
- Table Sharding - Very large datasets
- Time-Travel Queries - Unique capability
- CDC - Modern data stack integration
- Query Routing - Advanced optimization
If you're interested in implementing any of these features, please:
- Open an issue for discussion
- Create a design document
- Get feedback before implementation
- Follow the contribution guidelines
These features would transform pgsqlite from a protocol adapter into a comprehensive SQLite-based data platform suitable for production workloads while maintaining SQLite's simplicity and embedded nature.