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.
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.
Read the full design: what each part does, the choices behind it, what is claimed and what isn’t, and the roadmap.
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.