devLap

I built a query language in Rust that talks to PostgreSQL, MongoDB, MySQL and Redis, here's why

rust dev.to

I got tired of switching between four different query syntaxes every single day.

PostgreSQL in the morning. MongoDB in the afternoon. Redis for caching. MySQL for the legacy service nobody wants to touch. Four databases. Four mental models. Four times the cognitive load.

So I built CoffeeQL: a universal query language written in Rust that works across all of them.

The problem nobody talks about

Every backend engineer I know maintains multiple databases in production. It's not exotic, it's standard. PostgreSQL for relational data, MongoDB for documents, Redis for cache, MySQL for that one old service.

The problem isn't the databases themselves. The problem is the constant context switching.

You write:

SELECT * FROM users WHERE id = 1
Enter fullscreen mode Exit fullscreen mode

Then five minutes later:

db.users.findOne({ _id: ObjectId("...") })
Enter fullscreen mode Exit fullscreen mode

Then:

GET user:1
Enter fullscreen mode Exit fullscreen mode

Same intent. Three completely different syntaxes. Three different drivers. Three different error formats. Three different ways to think about the same operation.

I wanted one syntax. So I built it.

What CoffeeQL looks like

CoffeeQL has its own syntax... clean, readable, consistent across every database:

users[].where(id = 1).give(name, email)
Enter fullscreen mode Exit fullscreen mode

This single query runs against PostgreSQL, MongoDB, MySQL, or Redis — whichever you have connected. The engine figures out the translation.

Want to limit results?

users[].cup(10)
Enter fullscreen mode Exit fullscreen mode

Want to filter?

users[].where(created_at > "2024-01-01").give(name, email, created_at)
Enter fullscreen mode Exit fullscreen mode

Same syntax. Every database. Every time.

Why Rust

Two reasons: performance and correctness.

Rust's type system forces you to handle every edge case at compile time. When you're building a query engine that needs to translate one syntax into four completely different execution models.. that guarantee matters a lot.

The second reason is portability. CoffeeQL is published on both npm (via WebAssembly) and PyPI (via PyO3/maturin). One Rust codebase. JavaScript and Python both get native bindings. No duplicate logic, no drift between implementations.

Where it is today

CoffeeQL v0.3.1 is live right now:

  • ✅ 265/265 tests passing
  • ✅ PostgreSQL, MySQL, MongoDB, Redis support
  • ✅ Published on npm and PyPI
  • ✅ Query planning and explain() support 
# JavaScript
npm install coffeeql

# Python  
pip install coffeeql
Enter fullscreen mode Exit fullscreen mode

What's coming in v0.4.0

The current version handles query planning and routing. v0.4.0 brings actual execution:

  • Python real CRUD — asyncpg, motor, aiomysql, redis-py
  • npm rebuild with full error handling
  • Dart package on pub.dev
  • .raw() escape hatch for when you need it

v0.3 learned to speak. v0.4 will actually do things.

Try it

  • npm: npm install coffeeql
  • PyPI: pip install coffeeql
  • Docs & waitlist: coffeeql.dev

If you've ever felt the pain of maintaining multiple database syntaxes in one codebase — CoffeeQL is for you.

I'd love to know what databases you're running in production and what your biggest pain point is. Drop a comment below.

Built in Rust. Runs everywhere. One syntax to rule them all.

Source: dev.to

arrow_back Back to Tutorials