Skip to content
HackHydra
Register
HydraDB

Presents

Hack Hydra

Open Source · Online · $10K in Prizes

Build with the HydraDB OS repo

Dates

Aug 12-20, 2026

Register on LumaJoin the DiscordTracks

Teams of 1-4 · Online · Open source

Open SourceOnline$10K in PrizesAug 12-20, 2026Build with the HydraDB OS repoTeams of 1-4
01 / About

A nine-day, open-source hackathon by HydraDB.

HydraDB is a graph database built for AI applications, using object storage to stay fast and cost-efficient. From August 12–20, we're open-sourcing HydraDB and inviting developers globally to build across three technical tracks: enterprise knowledge, coding agents, and agent memory, while competing for up to $10,000 in prizes.

Days to build
9Days to build
In prizes
$10KIn prizes
Team size
1-4Team size
Online
100%Online
02 / Timeline

One clean open source repo.

The hackathon kicks off on August 12 and submissions close on August 20 at 11:59 PM PT. Any schedule or submission updates will be announced in Discord.

  1. Day 01
    Aug 12

    Kickoff

    The HydraDB open-source repo goes live and the build period officially begins. Projects must start on or after August 12.

  2. Day 01-09
    Aug 12-20

    Build

    Nine days to ship. The HydraDB team will be active in Discord throughout the hackathon for questions, repo walkthroughs, technical support and office hours.

  3. Day 09
    Aug 20

    Submission

    Submissions close at 11:59 PM PT. Submit your repository, demo video and completed submission form before the deadline.

  4. Wrap-up
    Aug 24

    Winners

    The HydraDB team and judging panel review all eligible submissions. Track winners, the Grand Champion, the Overall Runner-Up and the Best Use of HydraDB award are announced after judging is complete.

Note / Your work on the project has to start on or after August 12, 2026. See the rules below.

03 / Prizes

$10,000 in prizes.

Three tracks. Three track winners. One Grand Champion.

Total prize pool

$10,000

Split across three hackathon tracks, a final round and one special award for the best use of HydraDB.

The breakdown
Track 01 winner
$1,500
Track 02 winner
$1,500
Track 03 winner
$1,500
Grand Prize
+$3,500
Overall Runner-Up
+$1,500
Best Use of HydraDB
$500

All three track winners advance to the final round.

Final round

The three track winners go head to head.

Two of them pick up an additional award on top of the $1,500 they already won in their track.

Additional awards
Grand Prize+$3,500

On top of the track winner prize.

Overall Runner-Up+$1,500

On top of the track winner prize.

Final payouts

$5,000

Grand Champion

$1,500 track prize + $3,500

$3,000

Overall Runner-Up

$1,500 track prize + $1,500

$1,500

Third track winner

Track prize

Special award$500

Best Use of HydraDB

Awarded to the submission that demonstrates the most thoughtful, technically interesting or differentiated use of HydraDB.

That could look like

  • A particularly strong graph data model
  • A novel retrieval or reasoning approach
  • An interesting use of relationships, traversal or context
  • A use case that is hard to pull off with traditional vector or relational approaches

This one can go to any eligible submission, including a track winner.

Multiple track submissions

You can enter more than one track.

  • Teams are welcome to submit to more than one track.
  • Each submission has to be a meaningfully distinct project that addresses that track's problem statement. The same project cannot be entered in several tracks with only minor modifications.
  • A team can be a finalist in multiple tracks but can only take home one track winner prize. If the same team ranks first in more than one track, judges may award the other prize to the next-highest-quality eligible submission in that track.
  • Every team stays eligible for the $500 Best Use of HydraDB award, whichever track they enter or win.
How judging works

Judged in your track first, then across all three.

01

Within your track

Projects are first evaluated against the other submissions in the track they were entered in. The winner of each track advances.

02

Final round

Judges compare the three track winners holistically and pick the Grand Champion and the Overall Runner-Up.

A strong submission has
  • A functional product or demo
  • Real ingestion and retrieval workflows
  • A clear use case
  • A thoughtful technical implementation
Judges consider
  1. 01Technical execution
  2. 02Use of HydraDB and graph-native approaches
  3. 03Product completeness and usability
  4. 04Quality of results
  5. 05Originality

We care about working, thoughtful products, not just benchmark scores.

HydraDB reserves the right not to award a track winner prize if the submissions in that track do not meet the minimum quality bar.

To be eligible you need a complete submission by the deadline: repo, demo video and form.

Register
04 / Tracks

Three problems. Pick one.

Each track is a real problem HydraDB and its customers care about, and each one is a graph problem rather than something a vector database can handle. Every track has a $1,500 winner, and you are welcome to enter more than one with a distinct project.

Track 01

Enterprise context and ontology

Build an ontology out of real enterprise applications.

You get roughly half a million documents drawn from nine different sources: Slack, Gmail, Linear, Google Drive, HubSpot, Fireflies, GitHub, Jira and Confluence. They arrive with all the noise an actual company has, including misfiled documents, near duplicates and statements that flatly contradict each other.

Your job is to turn that into a clean, queryable ontology in HydraDB and then answer questions ranging from simple lookups to multi-hop reasoning, conflict resolution, and correctly recognising when the answer just is not in there.

Extraction is the easy part now that LLMs are cheap. The hard part is entity resolution and ontology alignment: deciding that “Sam”, “@soham” and “S. Ratnaparkhi” are one person, and figuring out which of two contradictory statements to trust.

Datasets
Enterprise RAG BenchSalesforce HERB
Track 02

Repos, dependencies and code as graphs

Search the graph, and catch chained vulnerabilities before they land.

Supply chain attacks through npm and PyPI are surging, and developer tools today fail to give real time, deep context on malicious dependencies.

When a package gets compromised, answer questions like
  • Which internal services are transitively exposed?
  • Which version of the dependency introduced the vulnerability?
  • Which applications resolved the compromised version while it was live?
  • Which other packages share maintainers or infrastructure with it?
  • Are there likely typosquat packages nearby?
  • What is the complete blast radius?

The central insight is that this is fundamentally a graph traversal and dependency problem, not a semantic similarity problem.

Pick A or B
A

Supply chain blast radius

Software supply chain attacks stopped being a nuisance and became an automated, worm driven problem. In the TanStack compromise this May, 84 malicious package artifacts were published across 42 packages within six minutes of the CI pipeline being breached. The worm went on to hit Mistral AI, UiPath and over 160 other npm and PyPI packages, self propagating and persisting in .claude/ and .vscode/ directories in a way that survived npm uninstall.

The defender's problem is speed. When a package is compromised at 09:00, which of your services are exposed by 09:06? That is a transitive reverse dependency closure over an ecosystem graph with tens of millions of versioned nodes, and it is the kind of question a vector index cannot answer at all.

Build the npm or PyPI dependency graph in HydraDB and answer it. Then go further: which packages share a maintainer with the compromised one, which lockfiles resolved to the bad version during the window it was live, and which names sit close enough to a popular package to be a typosquat.

B

Code graphs for IDE assistants

Every IDE assistant embeds repositories and retrieves chunks by similarity. Similarity is a weak proxy for relevance. Code needs call chains, type definitions, startup configs and tests.

Build a code graph in HydraDB and serve better context with it. This is the missing piece for editor wrappers today.

Track 03

Memory and context retrieval

Make your own mem0, and ace the benchmarks.

Build an agent memory layer for cross session continuity. It has to process chat histories spanning 30 to 40 sessions and 115,000 tokens per question.

The system has to synthesize facts across sessions, keep chronological order and track information that was later overwritten. Long context models drop 30 to 60% in accuracy here, and they mostly fail at abstention: knowing when the answer simply is not in the history and saying so instead of inventing one.

Datasets
LongMemEvalLongMemEval V2BEAM

Whichever track you take, the build starts on August 12. Nothing you write before then can go into your submission.

Ask in the Discord
05 / Submission

Submission requirements.

A complete submission requires three things: a submission form, a demo video of 3 minutes or less, and a public GitHub repository. All three must be submitted by the deadline.

Submission deadline

August 20, 202611:59 PM PT

The form closes then. Late submissions are not accepted unless we announce an extension.

Form opens at kickoff
01

Submission form

Submit your project through the official Hack Hydra submission form before the deadline.

The form will ask for

  • Project name
  • Short project description
  • Problem being addressed
  • What you built
  • Deployed project link, if available
  • How the project uses the HydraDB Open Source Repo
  • Tech stack used
  • Team members and individual contributions
  • GitHub repository link
  • 3-minute demo video link
02

3-minute pitch & demo video

Each team submits a video of 3 minutes or less introducing and demonstrating the project.

The video should cover

  • The problem you are trying to solve
  • What you actually built
  • A demo of the project working
  • How you used the HydraDB repo and why it matters

YouTube works fine. Unlisted links are fine too, as long as judges can watch without asking for access.

Anything past the 3-minute mark may not be reviewed.

03

Public GitHub repository

Every submission needs a link to the project's public GitHub repository.

The repository must contain

  • Complete source code for the submitted project
  • No participant-authored commits before August 12, 2026
  • A clear README
  • Setup and run instructions
  • An explanation of how HydraDB is used
  • Required environment or dependency information
  • Attribution for third-party libraries, APIs, datasets or open-source code used
  • An open-source license

Judges need to be able to open the repo and understand what you built.

06 / Rules

Build it during the hackathon.

Start on August 12, build something original, use HydraDB properly and keep everything open to inspection.

01

Build it during the nine days

  • Work on your project starts on or after August 12, 2026. Start a fresh repo, because judges can read commit history.
  • Existing open source libraries, frameworks, APIs, public datasets and AI coding assistants are all fair game.
  • The project has to be your team's own work. Credit anything you borrowed in the README.
02

Use HydraDB properly

  • HydraDB has to do real work in your project, not just sit in the README.
  • Be ready to say where it is used and what the project would lose without it.
  • All three tracks are built around HydraDB, so picking one is the easiest way to get this right.
03

Teams of 1 to 4

  • Every member has to be listed on the submission form.
  • You can only be on one team.
  • A team can enter more than one track, as long as each entry is a meaningfully distinct project. One team can still only win one track prize.
04

Submit by August 20

  • Everything goes through the official submission form by 11:59 PM PT on August 20, 2026.
  • The form closes on time. Late entries are not accepted unless we announce an extension.
  • Open your repo, video and demo links yourself before you submit. Broken links are the most common way people lose.
Disqualification

A submission may be disqualified for:

  • Work started before August 12, 2026
  • Missing or private GitHub repository
  • No open-source license in the repository
  • Missing demo video
  • HydraDB not used meaningfully
  • Submitted after the deadline
  • Breaking the rules or the code of conduct

Organisers can review repository history and ask for clarification if something looks off.

Judging is in two rounds: within your track first, then across the three track winners. The criteria are published with the prize structure.

How judging works
07 / FAQ

FAQ

If something is not covered here, ask in Discord. HydraDB team will gladly answer your questions.

  • Hack Hydra is a nine-day online hackathon by HydraDB running from August 12-20, 2026. Build a project using the HydraDB open-source repo, submit a public GitHub repository and a demo video, and compete for $10,000 in prizes.

Still stuck?

Ask in the Hack Hydra Discord.

Finding teammates, repo questions, office hours and every announcement happen there first.

Join the Discord
Registration is open

Nine days.
Start building.

August 12-20, 2026 · Online · $10,000 in prizes. Build solo or in a team of up to four.

Register on LumaJoin the Discord