cocoindex

ing "S3 bucket with versioning" across Terraform files returns random line matches because the tool has no concept of a resource block boundary. CocoSearch ships 8 grammar handlers — GitHub Actions (job/step boundaries), GitLab CI (job/stage boundaries), Docker Compose (service definitions), Helm (chart/template/values), Kubernetes (resource manifests), and Terraform (resource/data blocks). These split infrastructure configs at domain-aware boundaries and extract structured metadata, so search results land on complete, meaningful units. Without grammar handlers, your CI workflow YAML gets chunked on whitespace like any other text file. The grammar system is extensible — copy a template, define path patterns and separators, it gets autodiscovered. The dependency graph covers the same territory: Python, JS/TS, Go, plus Docker Compose (image refs, depends_on, extends), GitHub Actions (uses action/workflow refs, needs inter-job deps), GitLab CI (include, extends, needs, trigger pipelines), Terraform (module sources, required_providers, remote_state), and Helm (template includes, Chart.yaml subcharts). Forward trees, reverse impact analysis, and dependency-enriched search results. One thing I'm particularly happy with: a Markdown extractor tracks references from documentation to source files (inline links, code spans, frontmatter depends: fields). During PR review, impact analysis flags docs that reference changed files — so "you renamed cli.py but docs/architecture.md and CLAUDE.md still link to it" surfaces automatically instead of relying on reviewers to notice. Stack: PostgreSQL 17 + pgvector, Ollama for local embeddings (optional OpenAI/OpenRouter), CocoIndex, Tree-sitter. Runs as CLI, MCP server, web dashboard, or REPL. 32 languages, 8 grammar handlers, 10 dependency extractors. MIT licensed. Happy to answer questions about the chunking approach, grammar handlers, or anything else.

time & Reliability Safer async execution and correct cancellation, Centralized HTTP utility with retries + clear errors, and many others. Btw, we are also on Github trending in Rust today :) it has Python SDK. We have been growing so much with feedbacks from this community, thank you so much! We have lots of releases since last time i shared the project, a few recent ones (each contains 20+ releases) : - https://cocoindex.io/blogs/changelog-0310 - https://cocoindex.io/blogs/cocoindex-changelog-2025-10-19 - https://cocoindex.io/blogs/cocoindex-changelog-2025-08-18

-file... We’ve made 75+ releases since our last launch. Looking forward to learning your thoughts! Best, George

nt through pivoting hell. In all the projects I’ve built, data still sits in the center of the problem. I need to write custom logic to prepare data for AI and I need the data to stay fresh for AI to generate effective decisions or recommendations. So I started CocoIndex. Getting started: https://cocoindex.io/docs/getting_started/quickstart Examples: https://github.com/cocoindex-io/cocoindex/tree/main/examples If you prefer to read: https://cocoindex.io/blogs/tags/examples/ Would love to learn your thoughts. Thanks! Linghua

bind to different languages. I’ve made a few tutorials and new projects since last launch, with different use cases: - https://www.youtube.com/@cocoindex-io - https://cocoindex.io/blogs/tags/examples Previously, I’ve worked at Google on projects like search indexing and ETL infra for 8 years. After I left Google last year, I built various projects and went through pivoting hell. In all the projects I’ve built, data still sits in the center of the problem and I find myself focusing on building data infra other than the business logic I need for data transformation. The current prepackaged RAG-as-service doesn't serve my needs, because I need to choose a different strategy for the context, and I also need deduplication, clustering (items are related), and other custom features that are commonly needed. That’s where CocoIndex starts. A simple philosophy behind it - data transformation is similar to formulas in spreadsheets. The ground of truth is at the source data, and all the steps to transform, and final target store are derived data, and should be reactive based on the source change. If you use CocoIndex, you only need to worry about defining transformations like formulas. Data flow paradigm came in as an immediate choice. because there’s no side effect, lineage and observability just come out of the box. Incremental processing - If you are a data expert, an analogy would be a materialized view beyond SQL. The framework tracks pipeline states in database (Postgres) and only re-processes necessary portions. When data has changed, the framework handles the change data capture comprehensively and combines the mechanism for push and pull. Then clear stale derived data/versions and re-index data based on tracking data/logic changes or data TTL settings. There’s lots of edge cases to do it right, for example, when a row is referenced in other places, and the row changes. These should be handled at the level of the framework. At the compute engine level - the framework should consider the multiple processes and concurrent updates. It should consider how to resume existing states from terminated execution. In the end, we want to build a framework that is easy to build with exceptional velocity, but scalable and robust in production. Standardized the interface throughout the data flow - really easy to plugin custom logic like LEGO; with a variety of native built-in components. One example is that it takes a few lines to switch among Qdrant, Postgres, Neo4j. CocoIndex is licensed under Apache 2.0 https://github.com/cocoindex-io/cocoindex Getting started: https://cocoindex.io/docs/getting_started/quickstart I have rolled out over 25 releases since last HN launch and it has significantly improved in all aspects, especially supporting property graphs (Neo4j, Kuzu), supporting queue based CDC (AWS S3, SQS) and lots of infra updates including CLI, resilience and error handlings. Excited to learn your thoughts, and thank you so much! Linghua

ous projects and went through pivoting hell. In all the projects I’ve built, data still sits in the center of the problem and I find myself focusing on building data infra other than the business logic I need for data transformation. The current prepackaged RAG-as-service doesn't serve my needs, because I need to choose a different strategy for the context, and I also need deduplication, clustering (items are related), and other custom features that are commonly needed. That’s where CocoIndex starts. A simple philosophy behind it - data transformation is similar to formulas in spreadsheets. The ground of truth is at the source data, and all the steps to transform, and final target store are derived data, and should be reactive based on the source change. If you use CocoIndex, you only need to worry about defining transformations like formulas. *Data flow paradigm* came in as an immediate choice - because there’s no side effect, lineage and observability just come out of the box. *Incremental processing* - If you are a data expert, an analogy would be a materialized view beyond SQL. The framework tracks pipeline states in database, and only reprocessing necessary portions. When data has changed, framework handles the change data capture comprehensively and combines the mechanism for push and pull. Then clear stale derived data/versions and re-index data based on tracking data/logic changes or data TTL settings. There’s lots of edge cases to do it right, for example, when a row is referenced in other places, and the row changes. These should be handled at the level of the framework. *At the compute engine level* - the framework should consider the multiple processes and concurrent updates. It should consider how to resume existing states from terminated execution. In the end, we want to build a framework that is easy to build with exceptional velocity, but scalable and robust in production. *Standardized the interface throughout the data flow* - really easy to plugin custom logic like LEGO; with a variety of native built-in components. One example is that it takes a few lines to switch among Qdrant, Postgres, Neo4j. CocoIndex is licensed under Apache 2.0 https://github.com/cocoindex-io/cocoindex Getting started: https://cocoindex.io/docs/getting_started/quickstart Excited to learn your thoughts, and thank you so much! Linghua