MelodyDB.

A single system, compiled.

A real application is a database, an application server, a workflow engine, a search index, a cache, a queue and whatever else it has grown to need, plus the outside services they all call. Each one is well built. The failures happen where they meet, and no tool checks there, because no tool sees more than its own part.

MelodyDB is a bet that one compiler can see all of it. You describe the whole system in one language, Score. The compiler builds every part and checks them against each other. It ships and changes as one unit.

Experimental. Not released yet.

Leave an email to hear when there is something to run.

Three principles

  1. Trust the compiler. If it builds, the parts fit together. But a compiler can only enforce what it knows.
  2. Declare intent. Say what you want, and don’t decide how. Once you choose the implementation, nothing can tell what you meant.
  3. Describe the entire system. Not only the data. How the parts interact, and how it runs: operating it, securing it and paying for it.

What it looks like

Data, an access rule, a query, a workflow and a route, in one description. Nothing here names a database, an index, a queue or a server.

model Request {
  id: u64 key auto
  applicant: u64
  question: text(max: 4KiB)
  answer: text(max: 4KiB)?
}
visible Request = viewer.manager

fn my_requests() {
  [for row in Request if row.applicant == viewer.id select row]
}

workflow approval {
  revision v1(token: u64) {
    state Asking(token: u64) {
      do proposer.propose(request)
      on Returned(report) -> AwaitingApproval(token, report)
      on Unknown(reason)  -> Uncertain(token, reason)
    }
    state AwaitingApproval(token: u64, report: Agents.ProposalReport) {
      after 5m   -> Expired(token)
      on Approve -> Committing(token, report)
      on Reject  -> Rejected(token)
    }
    // more states
  }
}

exports server {
  http { POST "/requests" calls demo.submit { access user } }
}

Trimmed from Score in development. The syntax is still changing.

What the compiler builds from it

Read the full design: what each part does, the choices behind it, what is claimed and what isn’t, and the roadmap.

Who

I’m Doug Tarr. I spent eight years at MongoDB, where I was VP of Engineering for Search & Inference. I’m building MelodyDB on my own, with coding agents, and plan to open the source. I write at douglastarr.com, and you can reach me at [email protected] or on X at @doug_tarr.

© 2026 Douglas Tarr · [email protected]