Obsidian Index Service

🚀 Obsidian Index Service

This service monitors an Obsidian vault directory and indexes the metadata and full-text content of Markdown files into an SQLite database. Initially built for the mcp-server project, it was later replaced with an implementation using the Obsidian plugin API. However, it remains useful as a general-purpose, opinion-free indexing or synchronization tool, so it's published here.

✨ Features

It tracks file changes (creation, modification, deletion) in the Obsidian vault and stores all content in SQLite, accessible via Docker volumes. It captures:

• Path: File path (unique identifier)
• Title: Derived from the file name
• Parent Folder: Relative to the vault root
• Tags: From YAML front matter metadata
• Creation Date: File system timestamp
• Modification Date: File system timestamp
• Content: Full text of the note
• Status: Processing result (success/error)
• Error Message: Detailed information when processing fails

📦 Installation

Prerequisites

• Python 3.12 or higher
• Docker and Docker Compose (for containerized use)
• uv (optional but recommended)

Installation Steps

1. Clone the repository:

    git clone https://github.com/pmmvr/obsidian-index-service.git
    cd obsidian-index-service
   

2. Set up a virtual environment:

   • Using uv (recommended):

     uv venv
     source .venv/bin/activate # Linux/macOS
     .venv\Scripts\activate # Windows
     

   • Using python (standard method):

     python -m venv .venv
     source .venv/bin/activate  # Linux/macOS
     .venv\Scripts\activate     # Windows
     

3. Install dependencies:

   • Using uv (recommended):

     uv sync  # Install from uv.lock
     uv pip install pytest pytest-bdd pytest-mock  # For testing
     

   • Using pip:

     pip install -e .
     pip install pytest pytest-bdd pytest-mock  # For testing
     

💻 Usage Examples

Local Execution

pytest

📚 Documentation

Project Status

• Completed: Core indexing (metadata + content), Docker setup, file monitoring, database CRUD operations.
• Next Steps: Planned to create an API but switched to a plugin approach.

Future Steps (Potential as a Synchronization Tool)

With some refactoring, it can be used as a synchronization tool:

• Remote Backend: Add support for cloud storage (e.g., Dropbox) or servers.
• Synchronization Logic: Push local changes (content + metadata) to the remote, pull remote updates, and handle conflicts (e.g., last writer wins).
• Database Adjustment: Add sync_status and remote_id columns.
• File Monitor Update: Queue changes for synchronization, not just indexing.
• CLI Option: Add --sync to manually trigger or run continuously.
• Error Handling: Retry network failures and log issues.