DEV Community

Vivek Ojha
Vivek Ojha

Posted on

Vaachas: the operational layer for multi-database applications

#tooling #backend #database #architecture

Last updated: 2025-10-30

The problem

Modern products rarely live in a single datastore. Teams pair Postgres with search indexes, mix analytical warehouses with document stores, or juggle regional replicas for latency. Each new system adds bespoke routing code, queues, cron jobs, and credential sprawl. Engineers spend cycles maintaining glue instead of shipping features.

The Vaachas approach

Vaachas acts as a database gateway that sits between your application and every datastore you rely on. You:

  1. Register each database once in the Vaachas dashboard.
  2. Send one HTTP request with the writes you need.
  3. Decide where each read should land at runtime.

Vaachas handles ordered fan-out, retries, authentication, and per-database status so your services stay lean.

Core capabilities

  • Fan-out writes in order. One call writes to multiple databases with explicit sequence control (sync first, async later).
  • Runtime reads. Route queries to the datastore that makes sense for each request—no hardcoded wiring.
  • Observable workflows. Responses include per-database status and optional tracking IDs for long-running operations.
  • Credential vaulting. Connection details live in Vaachas; your services see only database IDs.
  • Provider flexibility. Supports PostgreSQL, MongoDB, Cassandra, and Elasticsearch providers out of the box.

Architecture snapshot 

Application → Vaachas Direct API → (sequence 0) Primary DB
                                  → (sequence 1+) Secondary DBs
                                  → Status endpoint for tracking
Enter fullscreen mode Exit fullscreen mode
  • Direct API accepts write and read payloads.
  • Status API lets you poll background work.
  • Dashboard manages database credentials, API keys, and developer tools.

Where teams use Vaachas today

  • Product catalogs: Keep transactional Postgres in sync with search indexes and analytics warehouses.
  • Customer data platforms: Distribute profile updates across document stores and reporting databases without ETL scripts.
  • Search backfills: Append Cassandra events to Elasticsearch with retries and tracking IDs.
  • Multi-region apps: Route reads to the closest shard while writes replicate to all required regions.

Quickstart in minutes

  1. Provision or connect your databases (Supabase, MongoDB Atlas, DataStax Astra DB, Elastic Cloud, etc.).
  2. Register each database in Vaachas using the dashboard.
  3. Generate an API key.
  4. Call the Direct API with a payload like: 
curl -X POST "https://api.vaachas.com/api/data/v1/direct" \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: YOUR_API_KEY" \
  -d '{
    "queryToDbsMap": {
      "INSERT INTO products (id, name, price) VALUES ('1111', 'Acme Anvil', 49.99);": [
        { "dbId": "postgres-db", "sequence": 0 },
        { "dbId": "elastic-db", "sequence": 1 }
      ]
    }
  }'
Enter fullscreen mode Exit fullscreen mode
  1. Monitor perDbStatus or poll /api/data/v1/direct/status/{requestTrackingId} for background work.

Need a deeper walkthrough? I published guides for https://medium.com/@vaachas/build-a-spring-boot-microservice-that-syncs-cassandra-elasticsearch-via-vaachas-417e44034d39, FastAPI, and Spring Boot teams.
https://medium.com/@vaachas/build-a-fastapi-product-catalog-that-fans-out-via-vaachas-72745b16a8a0

Why now

Databases proliferated, but the operational layer didn’t keep up. Vaachas aims to be the thin, reliable interface between your code and the storage systems you depend on—so adding a new datastore is a configuration change, not an engineering project.

What’s next

  • Additional provider integrations (MariaDB, etc.).
  • SDKs in the languages you rely on most.

We’re building in the open. Try the Developer Tools, send feedback in the Vaachas Discord - https://discord.gg/KK4bFQx7, and let us know which integrations would save your team the most time.

Top comments (0)