Hey all, I've been building noida-db: one Rust binary that implements the real wire protocols of Postgres, MySQL, Redis, Kafka and Elasticsearch. Your existing drivers, ORMs and CLIs connect to it unchanged, and it idles at about 2 MB of RAM. Why: my laptop was running a Docker Compose stack that idled at 2.5–4 GB just so npm run dev would work. For local development I don't need replication, clustering or tuning. I need the commands my app actually sends to behave correctly.
It's a local dev tool, not a production database. No clustering, no auth, no tuning, on purpose. What isn't supported yet is listed openly in the repo. Prebuilt for Linux, macOS and Windows (x64 and ARM). MIT licensed. Repo: https://github.com/its-banana-coder/noida-db
I'd love for people to point their app at it and tell me what breaks.
Top comments (2)
The local-dev boundary is useful. I'd want the compatibility tests to include failure behavior, not only successful driver connections: run the same ORM transaction against noida-db and Postgres, hit a unique constraint, then try another statement before rollback. Compare rows, error codes, and transaction state. A substitute that accepts the happy path but recovers differently could let an integration test pass for the wrong reason. How do unsupported commands behave: an explicit protocol error, or any best-effort/no-op cases?
Great point, and this is exactly the failure mode I worry about. I checked your scenario against the current release:
Postgres: a unique violation inside an ORM transaction returns 23505, the session moves to the aborted state, the next statement gets 25P02 ("current transaction is aborted"), and after ROLLBACK the table holds only the pre-transaction rows. That matches real Postgres.
MySQL behaves differently, as it should: 1062 Duplicate entry, but the transaction stays usable, because MySQL doesn't abort on a statement error. ROLLBACK then undoes everything.
Unsupported features fail loudly with an explicit protocol error, never a silent empty result: 0A000 feature_not_supported on Postgres, 1235 on MySQL, unknown command on Redis, and a 400 error on Elasticsearch for unknown query types.
There are a few deliberate best-effort cases, all listed in docs/LIMITATIONS.md:
Today, CI runs differential tests against the real servers, but they focus mostly on successful paths. You're right that failure behavior deserves the same treatment, so I'm adding differential tests that run the same failing transactions against noida-db and real Postgres/MySQL and compare rows, error codes and transaction state.
And I will keep on improving from here onwards till there is a good enough compatibility and usefulness of this tool