Goal
Implement the first DuckDB-based storage layer for ARGUS based on the storage research.
Why
ARGUS needs persistent local storage to move beyond temporary API requests and in-memory analytics. A first storage layer makes it possible to save normalized historical market data, read it back for analytics and prepare the project for later storage-first workflows.
This ticket focuses only on the database/storage foundation. Workflow orchestration, API fallback and service refactoring are handled in separate sub-issues.
Scope
-
Add DuckDB as the first storage dependency
-
Create the first minimal DuckDB schema based on the storage research:
data_sources
instruments
price_bars
-
Store normalized internal model data, not raw API response structures
-
Add a small storage/repository module for:
- initializing the database
- inserting/upserting data sources
- inserting/upserting instruments
- saving price bars
- reading price bars by instrument, source and date range
-
Keep storage logic separate from API clients, UI code and metric functions
-
Add tests for schema creation, saving and reading historical data
-
Document basic setup and usage
Out of scope
- Storage-first/read-through workflow
- API fallback when data is missing
- Refactoring
TimeSeriesService into MarketDataService
- Refactoring existing services
- GUI integration
- Analytics/reporting integration
- Cache strategy
Acceptance criteria
Goal
Implement the first DuckDB-based storage layer for ARGUS based on the storage research.
Why
ARGUS needs persistent local storage to move beyond temporary API requests and in-memory analytics. A first storage layer makes it possible to save normalized historical market data, read it back for analytics and prepare the project for later storage-first workflows.
This ticket focuses only on the database/storage foundation. Workflow orchestration, API fallback and service refactoring are handled in separate sub-issues.
Scope
Add DuckDB as the first storage dependency
Create the first minimal DuckDB schema based on the storage research:
data_sourcesinstrumentsprice_barsStore normalized internal model data, not raw API response structures
Add a small storage/repository module for:
Keep storage logic separate from API clients, UI code and metric functions
Add tests for schema creation, saving and reading historical data
Document basic setup and usage
Out of scope
TimeSeriesServiceintoMarketDataServiceAcceptance criteria
data_sources,instrumentsandprice_barsdocs/research-databases-and-storage.mdclosevalues inprice_barsNote
Priority: Should