CocoIndex recomputes affected records instead of every record
CocoIndex treats a data pipeline as a declared relationship between source state and target state. A Python function can walk files, split text, call an embedder, and declare rows in Postgres. The engine records dependencies so a changed file can update its own rows while untouched inputs stay cached. If transformation code changes, CocoIndex can invalidate outputs that depend on that logic. This is useful for AI indexes, where embedding or extraction calls make full refreshes expensive.
The quickstart is smaller than the repository's front page suggests. It converts PDFs from one directory into Markdown files in another, uses a local SQLite database through COCOINDEX_DB, and reruns only added or modified inputs. Deleting a source removes its declared target file. That example teaches the core idea without a vector database or model-provider key, although Docling is an extra dependency and the user's actual pipeline will choose its own source, transformation, and target services.
The 9-second build passed, while 192 tests failed
We cloned commit aee7b27 into a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. Installing the Python environment took 143 seconds, added 40 packages, and used 97 MB. The build completed successfully in 9 seconds. Pip-audit found 0 known vulnerabilities in the installed dependencies. Those results make the base package approachable and say nothing about the latency or cost of a user's model and storage choices.
The checkout was 44 MB with 1,169 files and about 185,892 source lines. Our scan found 10 CI workflow files, no Dockerfile, and no tests directory at the repository root. The source does contain Python tests under its own tree, which the harness found and ran. The absence of a root directory is only a structural signal; the failed pytest result is the evidence that matters for this commit and environment.
What happened when we ran it
Our test command ran for 356 seconds and exited with code 1. Pytest reported 309 passed, 192 failed, 125 skipped, and 8 collection or setup errors out of 509. It stopped after reaching 200 failures. A substantial part of the suite executed successfully, but this was nowhere near a clean pass, so the successful 9-second build should not be read as proof that CocoIndex's complete connector matrix works in a fresh container.
The log tail named errors in Amazon S3, FalkorDB, Neo4j, Postgres source and target, SurrealDB, Turbopuffer, and Valkey tests. It also listed pytest-trio and pytest-twisted near the failure summary. The log provided no single diagnosis covering all 192 failures, and our sandbox had no secrets. We can say the suite needs more environment or service preparation than our isolated run supplied. We cannot assign every failure to a missing database, credential, plugin, or network service without the corresponding log evidence.
SQLite is enough to learn it, while useful indexes add services
A local file-to-file pipeline can keep its tracking state in ./cocoindex.db. The more compelling examples introduce Postgres with vector indexes, LanceDB, Neo4j, SurrealDB, Kafka, S3, Google Drive, model APIs, or local embedding packages. Each connector brings a different authentication and lifecycle problem. CocoIndex coordinates declared state across those systems; it does not provision every database or supply provider credentials.
Start with one source and one target. Confirm initial backfill, a single-record change, deletion, transformation-code invalidation, and restart recovery. Then record the tracking database's growth alongside the target. Open issue 1779 describes one enterprise code-search user whose memoization information reached 17 GB while the vector table was 16 GB. That report is one workload, not a general benchmark, but it makes cache storage a capacity metric rather than an invisible implementation detail.
Pull-based ingestion and Rust parity remain open design edges
Open issue 20 asks for an API that can accept row insertions, updates, and deletions directly, describing the current mechanism as pull-only. That matters for systems where an upstream event already contains the change and rescanning a source is awkward. CocoIndex does support message queues among its source and target categories, but the specific push API requested in that issue should not be presented as an existing feature.
The repository's primary GitHub language is Rust, yet the documented user path is Python 3.10 through 3.13. Issues 2273 and 2326 compare the Rust SDK with Python and call out extra wiring or missing parity around batching, dispatch, target-state declaration, and streaming behavior. Rust work is active, but a team choosing CocoIndex today should evaluate the Python interface first unless it has verified the exact Rust APIs it needs.
August activity is high, and connector correctness still needs scrutiny
GitHub showed 11,408 stars, 75 combined open issues and pull requests, and a last push on August 26, 2026. Release v1.0.20 arrived on August 12 with fixes for target invalidation through memoization and LanceDB schema evolution, plus dependency updates. Current issue 2358 alleges that one Doris schema-reconciliation path can swallow an ALTER TABLE failure and leave tracked schema state out of sync with the database.
That issue is connector-specific, but the failure mode reaches CocoIndex's main promise: target state must reflect declared state. Test error handling, schema evolution, deletion, and recovery against the database versions you run. CocoIndex earns a trial when incremental recomputation has measurable value. The 309 passing tests show real implementation depth, while the 192 failures on our box say the trial must extend beyond installation and a toy local flow.