DEV.co
Vector Databases · Restream

reindexer

Reindexer is an embeddable, in-memory document database written in C++ with Go bindings, designed for fast complex queries without external dependencies. It supports full-text search, vector similarity (ANN/KNN), hybrid search, and claims performance up to 500K queries/sec on single-core workloads.

Source: GitHub — github.com/Restream/reindexer
808
GitHub stars
62
Forks
C++
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
RepositoryRestream/reindexer
OwnerRestream
Primary languageC++
LicenseApache-2.0 — OSI-approved
Stars808
Forks62
Open issues19
Latest releasev5.14.0 (2026-06-03)
Last updated2026-07-08
Sourcehttps://github.com/Restream/reindexer

What reindexer is

Core C++ implementation with Go API exposing ORM-like query builder and SQL interface. Features include composite indexes, joins, aggregations, transactions, TTL expiration, disk persistence via LevelDB, and basic replication/sharding. Memory overhead is ~32 bytes per document plus index costs; deserialized objects cached in Go layer.

Quickstart

Get the reindexer source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/Restream/reindexer.gitcd reindexer# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

High-throughput search in embedded systems

Integrate as a static library in Go applications requiring sub-millisecond latency for range queries, text search, and filtering at 50K+ queries/sec without maintaining a separate database service.

Real-time analytics with vector similarity

Execute ANN/KNN searches alongside traditional queries for hybrid search use cases (e.g., semantic search + filters) entirely in-process with low memory footprint.

Document-oriented caching layer

Replace external cache (Redis/Memcached) for applications needing complex queries on cached documents, leveraging composite indexes and aggregations without denormalization.

Implementation considerations

  • Embedding requires CGO and C++ compiler toolchain; build times and cross-platform compilation more complex than pure-Go libraries. Static linking recommended to avoid runtime library dependencies.
  • Memory model: all working data in RAM during normal queries; background async persistence via LevelDB. Monitor RSS to ensure dataset fits comfortably in available memory.
  • Query API is builder-pattern ORM-like; SQL interface available but Go struct binding is primary path. Plan schema design around index placement (max 255 user indexes per namespace).
  • Transaction support exists (sync and async batch modes) but implementation notes suggest care required; not ACID across namespaces. Review commit strategies (lazy, sync, async) for consistency requirements.
  • TTL and object cache are opt-in features; enable selectively to avoid memory overhead if not needed.

When to avoid it — and what to weigh

  • Multi-process or distributed write requirements — Reindexer is designed as embedded database; replication/sharding are described as 'basic.' Use externally-managed databases for systems requiring strong distributed consistency across processes.
  • Relational integrity is critical — Document-oriented design and join capabilities do not enforce foreign key constraints or ACID guarantees across namespaces. Avoid if strict relational invariants are mandatory.
  • Large datasets exceeding available RAM — While LevelDB persistence exists, primary design is in-memory. Data exceeding RAM becomes I/O-bound; consider external databases for multi-GB+ datasets.
  • Production deployments without C++ build infrastructure — Requires compilation of C++ core; Go bindings depend on CGO. DevOps overhead increases for teams without C++ toolchain familiarity.

License & commercial use

Apache License 2.0 (Apache-2.0). Permissive OSI-approved license permitting commercial use, modification, and distribution with attribution. No copyleft restrictions.

Apache-2.0 explicitly permits commercial use without royalty or derivative-work restrictions. Suitable for proprietary products. No commercial support, SLA, or indemnification evident from repository; assess internal support capacity or contact maintainers for options.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityModerate
DEV.co fitGood
Assessment confidenceHigh
Security considerations

No explicit security audit or penetration test results mentioned. C++ core introduces memory-safety risks (buffer overflow, use-after-free) common to C++ codebases; review code or threat model if processing untrusted input. No mention of encryption-at-rest or in-transit for persistence or replication. Authentication/authorization absent in embedded mode; server mode security posture unknown. Access control is application responsibility.

Alternatives to consider

SQLite with FTS5

Pure Go bindings (sqlite3 via cgo), built-in full-text search, no external service. Simpler C layer but slower for high-concurrency workloads and lacks vector search and composite index optimizations.

Elasticsearch (or Opensearch)

Mature distributed search engine with strong full-text and aggregation capabilities. Production-proven but heavier operational footprint, separate service deployment, higher latency for embedded use cases.

Typesense or Meilisearch

Fast in-memory or SSD-backed search APIs with simpler deployment (standalone binary). Built for search-focused workloads but less flexible for complex joins and lower-level query optimization.

Software development agency

Build on reindexer with DEV.co software developers

If you need fast in-process search with complex queries, vector similarity, and low latency, Reindexer is worth a technical spike. Assess build/deployment overhead and concurrency constraints against your architecture. Contact Restream or review benchmarks and source code for production readiness.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

reindexer FAQ

Can I use Reindexer in production?
Yes, it is actively maintained and used by Restream. Assess your own testing, especially around transactions and replication if those features are critical. No SLA from maintainers evident.
Do I need to run Reindexer as a separate service?
No, primary design is embedded (static library linked into Go binary). Server mode exists for external clients but adds deployment complexity; embedded mode is simpler and lower-latency.
What is the memory overhead per document?
Approximately 32 bytes per document plus 4-16 bytes per index. Actual overhead depends on index types and data shape. Object cache on Go layer incurs additional allocation for deserialized objects.
Does it support multi-process concurrent access?
No, single-process in-memory design. Replication exists (basic) for read replicas, but concurrent writes from multiple processes not supported. Use external database or application-level sharding.

Software development & web development with DEV.co

From first prototype to production, DEV.co delivers software development services around tools like reindexer. Our software development agency staffs experienced software developers and web developers for custom software development, web development, integrations, and ongoing support across vector databases and beyond.

Evaluate Reindexer for Your Use Case

If you need fast in-process search with complex queries, vector similarity, and low latency, Reindexer is worth a technical spike. Assess build/deployment overhead and concurrency constraints against your architecture. Contact Restream or review benchmarks and source code for production readiness.