TaglyDB

Not every dataset needs a schema

Scripts, pipelines, and one-off workflows produce data you’ll only ever look up by two or three attributes—a benchmark run, a feature-flag rollout, an inventory count, a release artefact, etc. Standing up a table and migrations for that is often more ceremony than the data deserves.

TaglyDB skips it. Store a JSON payload or a blob, attach flat key/value tags to it, and query later by tag combinations instead of a predefined schema.

curl -X POST https://api.taglydb.com/items \
  -H "Authorization: Bearer $TAGLYDB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tags": {"env": "prod", "service": "api"}, "data": {"benchmark": "p99"}}'

Tags in, tags out

Tag filtering follows AWS and Kubernetes conventions: repeat a tag key for OR, mix different keys for AND. Posting straight to /items is enough for a single record you’ll look up later; creating an index first gives a collection a stable, filterable home and per-item keys. Access from outside a trusted backend goes through signed, time-limited shareable URLs, and each integration gets its own API key that can be revoked individually without touching the others.

Built on the edge

The API is a Hono app on Cloudflare Workers with D1 behind it, so a request never leaves the edge to reach a database. The dashboard is a Next.js and TypeScript application deployed the same way—as a Worker rather than a long-running Node process—with Better Auth handling sign-in.

The trade-off

TaglyDB is deliberately not a general-purpose database. There’s no relational modelling, joins, or transactions across items—just tags, JSON, and blobs. That constraint is the point: for data you’ll only ever filter by a handful of attributes, it trades a query language for tag matching and skips the schema and infrastructure work a “real” database would demand.