mq-bridge
This MCP server lets you inspect, configure, run, and manage mq-bridge data routes, connectors, and processes.
Inspect all local mq-bridge processes, routes, health, throughput, message counts, pending messages, outcomes, and PIDs.
Describe supported endpoints, connector types, URI forms, parameters, and middlewares.
Generate headless
mqbCLI commands from route JSON, preserving complex fields and replacing credentials with environment placeholders.Publish single messages or batches to any endpoint, with optional metadata and middleware.
Start routes from an input to an output with optional middlewares, concurrency, batch size,
exit_on_empty, and message capture.List routes, query live route status, wait for routes to finish, and stop routes.
Read captured route messages destructively, returning each message once.
Report this MCP server's version, git hash, build profile, and build time.
Provides ClickHouse integration as a source/sink endpoint, supporting bulk inserts and resumable reads for moving data to and from ClickHouse.
Enables writing Parquet files to object storage that Databricks/Spark can load or query, supporting analytics and warehouse pipelines.
Enables writing Parquet files to object storage that DuckDB can load or query, supporting analytics workflows.
Provides an HTTP bulk document API endpoint for indexing data into Elasticsearch, useful for search index synchronization.
Provides SQL database integration with MariaDB as a source via cursor polling and as a sink via insert/upsert operations.
Provides an HTTP bulk document API endpoint for indexing data into Meilisearch, useful for keeping search indexes in sync.
Provides MongoDB integration as a source or sink, including change stream CDC modes for capturing changes.
Provides MQTT broker integration as an endpoint for receiving and sending messages.
Provides SQL database integration with MySQL as a source via cursor polling and as a sink via insert/upsert operations.
Supports Ollama through OpenAI-compatible APIs for LLM chat and embeddings, enabling classification, summarization, or embedding of messages.
Supports OpenAI-compatible APIs for chat and embeddings, enabling classification, summarization, or embedding of messages.
Provides PostgreSQL integration as a source or sink, including CDC via logical replication, cursor polling, and insert/upsert operations.
Provides RabbitMQ (AMQP) broker integration as an endpoint for receiving and sending messages.
Provides Redis Streams integration as an endpoint for receiving and sending messages.
Enables writing Parquet files to object storage that Snowflake can load, supporting analytics and warehouse pipelines.
Provides SQL database integration with SQLite as a source via cursor polling and as a sink via insert/upsert operations.
Provides integration with Supabase/PostgREST via the HTTP bulk document API endpoint for bulk document operations.
Enables writing Parquet files to object storage that Trino/Athena can query, supporting analytics pipelines.
What is mq-bridge?
mq-bridge is an asynchronous Rust library that moves messages and data between systems: Kafka, NATS, RabbitMQ, MQTT, MongoDB, PostgreSQL/MySQL/SQLite, Postgres CDC, ClickHouse, Redis Streams, HTTP, WebSocket, gRPC, ZeroMQ, AWS SQS/SNS, IBM MQ, cloud object storage, files, and in-memory channels. Every endpoint sits behind the same batch-shaped receive_batch / send_batch traits, so any source can feed any sink.
A route connects one input to one output and shapes the data on the way: transform, filter, switch, fan out, enrich, retry, rate-limit, deduplicate, or answer a request, all by configuration. The engine is fast: a typing transform runs at ~1.6M rows/s, ~19.5x Redpanda Connect on the same job. Structural endpoints such as switch, fanout and sequence nest freely inside a route, and wrong delivery combinations fail when the route starts, not in production. Where configuration isn't enough, you add a handler in Rust, Python or Node.js. Batching, ack/nack, commit ordering and broker I/O stay in the Tokio-based core, so your code works with plain CanonicalMessages and doesn't handle Kafka offsets or AMQP nacks.
Try it in the CLI, ship it in your service: mq-bridge-app runs a route from the command line (mqb), as a server, desktop app or MCP server; the same config runs as a library inside your Rust, Python or Node.js service when you need lower latency or want the pipeline in your production code. No daemon or platform to operate.
Bridge between ecosystems: two plugins add over 100 more inputs and outputs: Redpanda Connect's components and faucet's connectors. They load only when a route uses them and run in the same process, so one route can read with one framework, process with a second and write with a third, under one ack chain and with mq-bridge's retry, DLQ and deduplication around all of it. See Combine ecosystems in one route.
Related MCP server: SEOSiri Data Pipeline MCP
Use cases
Problem | Guide with a runnable example |
A RAG or semantic-search index drifts from its Postgres source | Keep a vector index in sync with Postgres: CDC → embeddings → Qdrant |
Search results show what MongoDB no longer has | Keep a search index in sync with MongoDB: change stream → Meilisearch |
The warehouse is a day behind and misses every change in between | Stream Postgres changes into a warehouse: CDC → Bloblang → Snowflake |
Free-text messages need routing by what they say | |
Events need a database record and per-key totals to act on | |
A service must update its database and publish an event atomically | |
Tests for Kafka, NATS or RabbitMQ consumers need a running broker |
Quick Start
Install the library for your language:
Language | Package | Install |
Rust |
| |
Python |
| |
Node.js |
| |
C / C++ |
| |
Nim |
|
Describe a route — here Kafka → NATS with retries — in routes.yaml:
kafka_to_nats:
input:
kafka: { url: "localhost:9092", topic: "orders", group_id: "bridge" }
output:
middlewares:
- retry: { max_attempts: 5 }
nats: { url: "nats://localhost:4222", subject: "orders.processed" }Run it:
from mq_bridge import Route
Route.from_file("routes.yaml", "kafka_to_nats").run() # blocks; use start() to keep goingimport { Route } from "mq-bridge";
Route.fromFile("routes.yaml", "kafka_to_nats").start();mq_bridge::deploy_file("routes.yaml").await?; // every route in the file, in the backgroundAttach a handler (with_handler / withHandler) when you need business logic in between. No code at all? mq-bridge-app runs the same engine from the command line or a desktop UI:
mqb copy 'kafka://localhost:9092?topic=orders' 'nats://localhost:4222?subject=orders.processed'Capabilities at a glance
Every row works from the Rust crate, the Python and Node.js packages, and the zero-code app; the Cargo feature is only needed when you build the Rust crate yourself. The linked book documents the library as well as the app.
Capability | How (endpoint / middleware · Cargo feature) | Docs |
Message brokers: Kafka, NATS (JetStream), RabbitMQ (AMQP), MQTT, Redis Streams, AWS SQS/SNS, IBM MQ, ZeroMQ |
| |
Change Data Capture (CDC): stream Postgres or MongoDB changes to Kafka, files, a warehouse, … |
| |
SQL databases: PostgreSQL, MySQL, MariaDB, SQLite as source (cursor polling) or sink (insert / upsert) |
| |
MongoDB as source or sink |
| |
ClickHouse bulk insert and resumable reads |
| |
Search engines and other bulk document APIs (Meilisearch, Typesense, Elasticsearch, Qdrant, PostgREST / Supabase) |
| |
LLMs and embeddings over an OpenAI-compatible API (OpenAI, Ollama, vLLM, …): classify, summarise or embed each message |
| |
Object storage: S3 (and S3-compatible, e.g. R2), GCS, Azure Blob, or a local directory, as Parquet, JSONL or CSV |
| |
Files: CSV and JSONL, read and write |
| |
Analytics / warehouses: Snowflake, BigQuery, Databricks / Spark, Athena / Trino, DuckDB via Parquet on S3/GCS/Azure. These are not native connectors: mq-bridge writes the Parquet files, the warehouse loads or queries them |
| Snowflake · BigQuery · Databricks / Spark · Athena / Trino · DuckDB |
HTTP, gRPC, WebSocket as server or client, including request/reply |
| HTTP · gRPC · Request / reply |
Schema validation and type coercion (JSON Schema subset, field mapping) |
| |
Reliability: retries, dead-letter queue, deduplication, rate limiting |
| |
Broker-free tests: run a route or handler against in-memory channels, no Docker |
| |
ETL without code |
| |
More systems through plugins: Apache Pulsar, Meilisearch, Redpanda Connect's inputs, outputs and processors, and faucet's sources and sinks (MySQL / SQL Server / Oracle CDC, Snowflake, BigQuery, Iceberg, Delta, GraphQL APIs, …) | native plugins · | Plugin endpoints · Connect plugin: inputs, outputs, processors · faucet plugin |
The Connect plugin links only Redpanda Connect components free of Redpanda Community License code (bundled code is Apache-2.0 and MIT), so some upstream components, such as its Kafka, AWS and Snowflake ones, are not included; see what is not included. Native endpoints and the faucet plugin cover most of that gap.
Combine ecosystems in one route
No single framework has every connector and processor. mq-bridge combines three in one route:
Parts from | What they bring | Count |
mq-bridge, native | Kafka, NATS, RabbitMQ, MQTT, IBM MQ, Postgres and MongoDB CDC, SQL, object storage, paged HTTP APIs ( | 20+ transports |
Redpanda Connect's components; Bloblang processors as middleware on any endpoint | 56 inputs, 68 outputs, 86 processors | |
faucet's connectors: MySQL / SQL Server / Oracle CDC, Snowflake, BigQuery, Iceberg, Delta, GraphQL, Singer taps; exactly-once into supporting sinks | 41 sources, 34 sinks |
Plugins load only when a route names them and run in-process. Acks, commits, retry, dlq and deduplication work across all parts, and plugin endpoints nest inside switch, fanout and sequence. Where a system has both, prefer the native endpoint.
Scenario | Native | Connect | faucet |
Postgres into Snowflake, backfill then changes, exactly once |
|
|
|
MySQL, SQL Server or Oracle changes into Kafka |
|
|
|
Sensor data: live statistics, alerts to a time-series DB, all to the lake |
|
|
|
Install the Connect plugin with brew, conda, pip or npm (install), the faucet plugin with pip install mq-bridge-faucet or npm install mq-bridge-faucet (README).
For AI agents: llms.txt is a curated index of the documentation, and
npx skills add marcomq/mq-bridge installs a skill that
teaches Claude Code, Codex and other agents to drive mqb.
Benchmarks
Like-for-like ETL comparisons, measured through the zero-code mq-bridge-app; every number, baseline and command is in the ETL benchmark harness:
Scenario | mq-bridge | Compared with |
CSV → JSONL, 1M mixed-type rows (~116 MiB) | 3,134,796 rows/s, ~29 MiB RAM | Meltano ( |
Kafka → file, 1M rows, no transform | 878,105 rows/s, ~160 MiB RAM | Sea Streamer, mimalloc build: 492,465 rows/s, ~894 MiB RAM — mq-bridge ~1.8x faster (also ~1.8x vs. its default-allocator build) |
CSV → JSONL, 1M rows, typing | 1,594,896 rows/s | Redpanda Connect 4.112.0, Bloblang |
Kafka → JSONL, 1M rows, projection | 766,280 rows/s | Redpanda Connect 4.112.0: 65,741 rows/s — mq-bridge ~11.7x faster, under half the memory, identical sink bytes |
The CSV row reuses an existing, independently published 1M-row CSV → JSONL workload, on a byte-identical fixture: 7 mixed-type columns, seed 42, 121,981,421 bytes, SHA-256 a84894e0…0c45b221 (full definition). Whole-process wall-clock, no transformation, Meltano run on the same machine and file.
All figures: mq-bridge 0.4.20, except the Redpanda Connect rows, which were measured together with their native mq-bridge figures in one later session (scenario 10). DuckDB is a throughput ceiling for the conversion itself, not an ETL tool.
External benchmark: both the Rust library (mq-bridge) and the Python binding (mq-bridge-py) are entries on the third-party http-arena.com leaderboard, which compares HTTP frameworks by requests per second (live, so rankings shift over time). It measures mq-bridge's HTTP (and WebSocket) serving path, which is one endpoint among many, not broker or ETL throughput; those are covered under Benchmarks. See the Python analysis notes for the local comparison harness.
Why mq-bridge
What you get from one engine, whichever language you call it from:
20+ native transports, 100+ more via plugin, one API: every connector listed above, plus
dir_spool(a crash-safe directory FIFO queue), behind the samereceive_batch/send_batchshape.Redpanda Connect reach: the Connect plugin adds Redpanda Connect's production-proven components — 56 inputs and 68 outputs as endpoints, plus 86 processors, most of which also run as middleware on any endpoint — while mq-bridge keeps routing, batching, retries, DLQ and deduplication.
faucet reach: the faucet plugin adds faucet's 41 sources and 34 sinks as one
faucetendpoint: MySQL / SQL Server / Oracle CDC, Snowflake, BigQuery, Iceberg, Delta, GraphQL APIs and Singer taps, with commit-token exactly-once into sinks that support it.The best of three frameworks in one route: native endpoints, Connect and faucet parts mix freely in one route and one process; see Combine ecosystems in one route.
Change Data Capture: stream row-level changes from Postgres (logical replication /
pgoutput) and MongoDB (change streams) as flat rows with an operation marker.Restart-safe delivery: batch-aware ack/nack with commit sequencing for cumulative-ack brokers; the integration suite shows no data loss during in-flight broker restarts, including a Postgres CDC restart-safety test.
Reliability middleware, not a framework: retries, dead-letter queues, deduplication, rate limiting, and cookie/session persistence wrap any endpoint.
Polyglot on one engine: the same Rust core ships as native Python and Node.js bindings; routing, batching, and broker I/O stay in Rust.
TLS everywhere, one config shape: a single
TlsConfigblock (CA bundle, client cert/key for mTLS, insecure-skip) is reused across transports.ca_file: "$.os"trusts the OS CA store and"$.bundled"the built-in Mozilla roots; what each endpoint supports.Self-hosted, no daemon: generate config in the optional UI, paste it into your code, run it in-process. No hosted control plane, no separate scheduler.
Prefer not to write code? mq-bridge-app runs the exact same engine as a standalone, zero-code ETL service configured entirely by YAML or environment variables. It ships a Postman-style UI to build, send, and inspect messages against a route, and can import Postman collections and AsyncAPI documents to scaffold routes and endpoints. Everything about the app — install, CLI, UI, cookbook, tuning — is in the 📖 book.
When to use mq-bridge
Hybrid Messaging: Connect systems speaking different protocols (e.g., MQTT to Kafka) without writing a custom adapter for every pair.
Batch-heavy Pipelines: Increase throughput by moving messages in batches while keeping per-message ack/nack decisions.
Infrastructure Abstraction: Write business logic against
CanonicalMessages and swap the underlying transport later.Resilient Pipelines: Apply retry, DLQ, deduplication, limiter, and cookie/session behavior consistently around endpoints.
Database Integration: Combine databases with message brokers, for example by ingesting messages into SQL/MongoDB or forwarding outbox rows to a broker.
Sidecar / Gateway: Run the bridge beside another service to ingest, filter, and route messages before they reach the core application.
When NOT to use mq-bridge
Stateful Stream Processing: For windowing, joins, or complex aggregations over time, dedicated stream processing engines are more suitable.
Domain Aggregate Management: If you need a framework to manage the lifecycle, versioning, and replay of domain aggregates (Event Sourcing), use a specialized library.
mq-bridgehandles the bus, not the entity.Protocol-Specific Power Features:
mq-bridgeintentionally exposes a common subset: publish/consume, pub/sub where possible, request-reply where possible, batching, middleware, and ack/nack handling. If your application depends on highly specific broker features, using that broker's native client directly may be better.
Documentation
The 📖 mq-bridge book covers the library and the app. Connectors, middleware and tuning use the same settings in both.
I want to… | Read |
Embed the library, write handlers, publish from code | Quick start: library · Embed the library · Bindings API · docs.rs |
Move data without code | |
Configure a connector | Connectors, with YAML and URL examples for each |
Know what each backend supports (subscriber mode, request-reply, nack, CDC vs. polling) | Overview & capabilities · Capability tables (acknowledgement, commit order, replies, TLS) |
Add retries, DLQ, dedup, transform, routing | |
Understand delivery guarantees and idempotent sinks | |
Build request/reply or CQRS-style flows | |
Tune throughput | |
Write my own endpoint, middleware or plugin | |
Understand the internals |
Status
mq-bridge was created in 2025. Its reliability behavior is exercised by an automated integration and performance suite across supported endpoints, in each of the queue and subscriber modes that endpoint supports:
All endpoints showed no data loss during in-flight broker restarts; MQTT publish confirmation was hardened until a chaos test drove in-flight loss to zero.
Postgres CDC has a restart-safety test: an un-acked, in-flight batch is redelivered after a database restart with no loss and no gap.
It is used as rust library in armature and as python lib in omniload.
Stability and Rust version
Since 1.0 the Rust API follows semantic versioning: the crate root and the modules models, traits, errors, outcomes, extensions, plugin (the SDK), type_handler, publisher, route and checkpoint. The implementation modules endpoints, middleware, support and test_utils may change in a minor release, and so may the major version of a re-exported driver crate (mq_bridge::sqlx, mq_bridge::rdkafka, ...).
A minor release may add a configuration field, a variant of a configuration or error enum, and raise the minimum Rust version. Code that writes config structs with ..Default::default() and gives a match on these enums a _ arm compiles unchanged across such releases.
The minimum Rust version is 1.89. The features aws, sqlx and postgres-cdc, and so full, need 1.94.1; zeromq-omq needs 1.93.
Running Tests
The project includes integration and performance tests. Most backend tests require Docker.
To run the performance benchmarks for all supported backends:
cargo test --test integration_test --release -- --ignored --nocapture --test-threads=1To run the criterion benchmarks:
cargo bench --features "full"Criterion numbers vary with the machine they run on; for comparable throughput figures use the integration performance test above, or see the ETL benchmarks.
Contributing
Contributions are welcome. See CONTRIBUTING.md for setup notes, code style, and pull request guidelines.
AI Disclaimer
This library was written with a lot of AI assistance. The core started as my own code; many endpoints and docs were expanded with Gemini, CodeRabbit, Claude, and Codex, which made adding transports much faster once the endpoint traits were stable.
Generated code can look plausible while missing important details, so I review every commit manually, clean up and refactor the output, and rely on the integration suite to catch regressions. I trust the current code as much as if I had written it myself. Given the large feature set there may still be open issues; the current focus is testing and documentation.
License
mq-bridge is dual-licensed under either the MIT license or the
Apache License, Version 2.0, at your option.
Binary distributions carry their applicable third-party terms in
THIRD_PARTY_LICENSES.txt. Their current maintenance process is documented in
docs/THIRD_PARTY_LICENSES.md.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in mq-bridge by you, as defined in the Apache-2.0 license, shall
be dual licensed as above, without any additional terms or conditions.
Available Tools
11 toolsbridge_statusARead-only
Report every mq-bridge process this user is running on this machine — CLI jobs (mqb copy, headless configs), other MCP servers, the web UI and the desktop app — with their routes and consumers: connector types, running/healthy, outcome, current rate (throughput), average_throughput, total messages (message_sequence), pending and started_at_ms. Read-only; routes of other processes cannot be stopped from here. The entry whose pid equals current_pid is this server. Error text of other processes is redacted to error.
Inputs: no named parameters.
describeARead-only
Describe the endpoints and middlewares this build supports, the same data as mqb list --json / mqb describe <name> --json: each endpoint's endpoint type (the JSON key publish/start_route take), URI form, example and typed params (also its config fields), and each middleware's params. Pass name to narrow it to one entry. Call it before writing publisher or route JSON for a connector you have not used yet.
Inputs: name.
generate_cli_commandARead-only
Generate a copyable, headless mqb command for a route. Accepts the same route JSON and tuning overrides as start_route, but does not start anything. The command embeds canonical JSON with POSIX shell quoting so fields that have no compact copy-URI representation are preserved. Credential values are replaced by environment variable placeholders and the required variable names are returned separately.
Inputs: route (required), name, batch_size, concurrency.
list_routesARead-only
List the routes started by this server, with their live connection health, total messages moved, current message rate, and achieved average rate. For one route's full status use route_status; for routes of other mq-bridge processes use bridge_status.
Inputs: no named parameters.
publishA
Publish one message or a batch of messages to any endpoint. The endpoint is supplied inline in publisher as JSON keyed by type (e.g. {"kafka": {"url": "...", "topic": "..."}}); this is independent of routes. Provide either message or messages; each message has a payload and optional metadata headers (e.g. kind for the message type, correlation_id). Returns the send outcome (an acknowledgement, or the endpoint's reply for request/reply endpoints). Use it for ad-hoc sends; to move data from a source endpoint, use start_route. Messages are written to the external system and cannot be recalled.
Inputs: publisher (required), name, message, messages.
route_messagesADestructive
Return the most recent messages captured on a route, newest last. Only routes started with capture_last capture anything. Reads are destructive: each message is returned once, so repeated calls yield only what arrived since the last call.
Inputs: name (required).
route_statusARead-only
Report the live status of one route (by name) or all routes: connection health, whether it has finished, the total number of messages it has moved, its current rate (messages_per_second), and the rate it achieved overall (average_messages_per_second over elapsed_s). Quote the average for a finished job: the current rate decays to ~0 once a route stops moving data. To wait for a job to finish, call wait_route once instead of polling this.
Inputs: name.
server_infoARead-only
Report this MCP server's build identity: crate version, git_hash (with a -dirty suffix if the working tree had uncommitted changes at build time), build profile (debug/release), and build_time. Use it to confirm which binary is actually running before trusting throughput numbers.
Inputs: no named parameters.
start_routeADestructive
Create and run a route that moves messages from its input (source) endpoint to its output (sink) endpoint, each keyed by connector type. Supports route options like concurrency, batch_size, and exit_on_empty (drain the source then exit; otherwise the route runs continuously until stopped). Either endpoint may carry a middlewares array — retry, dlq, deduplication, limiter, transform, compression, encryption, pack/unpack, buffer, delay, timeout, weak_join, cookie_jar, metrics — e.g. {"sqlx": {...}, "middlewares": [{"retry": {"max_attempts": 3}}]}. concurrency/batch_size may be given inside route or as top-level arguments — the top-level argument wins, and an unset value becomes the app default (4 / 1024, or the batch size the output endpoint's schema declares). Returns the route name for use with wait_route / route_status / stop_route, plus the tuning that took effect.
Inputs: route (required), name, batch_size, concurrency, +1 more.
stop_routeADestructive
Stop a route started by this server, by name. Use it to end a continuous route or abandon a drain; a route started with exit_on_empty stops by itself, so wait for it with wait_route instead. Sends the shutdown signal and returns without waiting for the route to exit; the route is removed from list_routes, and messages captured for route_messages but not yet read are discarded (their count is returned). Returns the total messages it moved plus the rate it achieved (average_messages_per_second over elapsed_s).
Inputs: name (required).
wait_routeARead-only
Block until a route finishes, then report how it ended. Use this instead of polling route_status for a job started with exit_on_empty: it costs one tool call regardless of how long the job runs. Returns finished (false if timeout_ms elapsed first — the route is left running), the outcome, the total messages moved and the rate achieved. An outcome of failed carries the cause in error. Default timeout 60000 ms, maximum 18000000 ms.
Inputs: name (required), timeout_ms.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 11 tools
Most tools are clearly separated and the descriptions actively cross-reference each other (bridge_status vs list_routes vs route_status, wait_route vs polling, generate_cli_command vs start_route). The one real overlap is that route_status called without a `name` returns the same all-routes summary as list_routes, and the cluster of status/health tools (server_info, bridge_status, list_routes, route_status, wait_route) takes careful reading to sort out.
A predictable scheme runs through almost everything: verb_noun for actions (start_route, stop_route, list_routes, wait_route, generate_cli_command) and noun_status/noun_messages for read-only reporters. The only deviations are the bare verbs `describe` and `publish`, plus `server_info`, which don't fit either pattern cleanly but are still readable.
Eleven tools is squarely in the well-scoped range, and each maps to a distinct step in the job lifecycle: discover schemas, generate a command, start/wait/stop a route, read status and captured messages, plus machine-level and build identity. Nothing looks like filler.
The route lifecycle is fully covered — schema discovery via describe, optional command generation, start, wait, status, message capture, and stop — plus ad-hoc publish and cross-process visibility via bridge_status. Minor gaps remain: there is no ad-hoc single-message consume/poll (you must stand up a route with capture_last), no pause/resume, and stopping routes belonging to other processes is explicitly impossible by design.
Maintenance
Related MCP Connectors
List reverse-ETL sources, destinations, models, syncs and runs; trigger syncs into SaaS tools.
Push rows from a dataset, file or Google Sheet into a Postgres, Supabase, Neon or MySQL table.
Build and manage data pipelines, add custom connectors, and chat with your data.
Streamkap CLI & MCP server - manage CDC pipelines, sources, destinations, and transforms
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceMCP server with 32 tools for ETL ingestion, AI-generated data quality rules, AI transformations, vector search, and natural-language SQL. Works across Postgres, MongoDB, Kafka, S3/MinIO, HashiCorp Vault, and five vector stores (Qdrant, Weaviate, Milvus, Chroma, pgvector).13Apache 2.0
- AlicenseBqualityBmaintenanceA sovereign, high-speed, local-first Big Data Ingestion, Filtering, and Analytical Pipeline Orchestrator.7MIT
- AlicenseAqualityCmaintenanceEnables querying and mutating data across multiple sources (CSV, Google Sheets, SQLite, PostgreSQL, MySQL, MongoDB, Oracle) through a dynamic GraphQL API, with flexible filtering, batching, persisted queries, and dynamic source switching.84 npmMIT
- AlicenseAqualityBmaintenanceTurn PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SQLite or Snowflake into MCP tools and a REST API, with API keys and per-table role-based access.8171MIT