← Back to home
Comparison · DevOps

Appsmith vs Tigris

Side-by-side trajectory, velocity, and editorial themes.

A
Appsmith
DEVOPS
2.1

Appsmith spent six months in a sustained security-patch cycle, capped by a release with 15+ named advisories.

◆ Current state

Appsmith's recent release stream is dominated by security work. v1.99 alone landed roughly fifteen security-tagged fixes — multiple named GHSAs (super-user race condition, SSRF via send-test-email, OAuth2 callback ACL bypass, application snapshot delete permission, expanded metadata denylist), critical CVE patches (CVE-2025-70952, CVE-2026-33937 in handlebars, CVE-2026-22732 around Spring Security headers), AQL injection prevention in the ArangoDB plugin, and several reflected XSS and email-normalization fixes. The same pattern repeats in v1.98 (SQL injection in UQI filters, simple-git critical CVE), v1.96 (arbitrary file write outside repo scope, OS command injection in in-memory Git, XSS in Table HTML cells), and earlier. Feature work continues alongside but at a much smaller volume — Redis TLS, BetterBugs SDK, Favorite Applications V2, Helm extraVolumes.

◆ Where it's heading

The arc is clear: Appsmith is absorbing the output of what looks like a sustained external audit (or several converging ones) and using minor releases as the patch vehicle. The diversity of vuln classes across the ArangoDB plugin, Spring Security headers, OAuth2 callback, in-memory Git, snapshot deletion permissions, and metadata denylist points to a broad-surface review rather than a single component. Feature work isn't stalled, but it's clearly running second to the security queue.

◆ Prediction

Expect at least one or two more 1.9x releases to keep landing security patches before a 2.0 line emerges. Watch for a release that bundles fewer security items than features — that's the signal the audit cycle has caught up. Likely product-side bets are continued data-source TLS coverage and more granular permission scoping (the GHSAs around snapshots and OAuth2 lookup suggest the permission model is being tightened systematically).

T
Tigris
DEVOPS
7.5

Tigris turns its object store into agent infrastructure with Agent Kit, agent-shell, and durable global streams.

◆ Current state

Tigris's release stream is a sustained product-marketing push around AI-agent storage primitives. Agent Kit landed as a TypeScript SDK exposing bucket forks, workspaces, checkpoints, and event coordination. agent-shell put a virtual bash environment with persistent storage in front of those primitives. Durable global streams via S2 Lite extended the object store into a streaming substrate suitable for per-agent reasoning traces. Around the launches, case studies and tutorials (Basic Memory, the $10 self-updating knowledge base) make the pitch concrete.

◆ Where it's heading

Tigris is staking a position that the right substrate for AI agents is not a database, vector store, or queue — it is a globally-distributed, fork-able object store. Each blog and SDK in this batch reinforces that thesis from a different angle: storage as message queue, fork-per-agent sandboxing, storage-protected agent containment, streams for reasoning traces. The competitive map being drawn includes R2, S3 Express, Backblaze, and the agent-runtime vendors (Modal, E2B), not other databases.

◆ Prediction

Expect a managed Vector or Lance-index surface on top of buckets to compete more directly with Turbopuffer and Pinecone, and a Python counterpart to the @tigrisdata/agent-shell TypeScript runtime to widen the agent-developer surface area.

See more alternatives to Appsmith
See more alternatives to Tigris