mirror of
https://github.com/hanzoai/papers.git
synced 2026-10-22 17:20:17 +00:00
zeekayandHanzo Dev
34ba5b1cee
The prior-work section describes the 2022 backend by category, and the comparison table and production section cover the systems Base is measured against. hanzo-stack-comparison and hanzo-datastore drop one reference each. hanzo-base.pdf had no source in the repo and is superseded by hanzo-base-runtime. Committed PDFs rebuilt with make. Co-authored-by: Hanzo Dev <[email protected]>
70 lines
3.1 KiB
TeX
70 lines
3.1 KiB
TeX
\section{Runtime: Hanzo Base}
|
|
|
|
\label{sec:runtime}
|
|
%% ============================================================================
|
|
|
|
\subsection{Overview}
|
|
|
|
Hanzo Base is an application runtime with a Goja-based JavaScript VM for server-side scripting, native Hanzo IAM integration, multi-tenant data isolation via organization-scoped collections, and S3-compatible storage backends. It provides a real-time database (SQLite or PostgreSQL), REST API auto-generation, file storage, and an admin dashboard in a single binary.
|
|
|
|
\subsection{Feature Matrix}
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\caption{Application runtime comparison.}
|
|
\footnotesize
|
|
\begin{tabular}{@{}lccccc@{}}
|
|
\toprule
|
|
Feature & \rotatebox{60}{Base} & \rotatebox{60}{Supabase} & \rotatebox{60}{Firebase} & \rotatebox{60}{Hasura} & \rotatebox{60}{Appwrite} \\
|
|
\midrule
|
|
Single binary & \yes & \no & \no & \no & \no \\
|
|
JS scripting & \yes & \yes & \yes & \no & \yes \\
|
|
Real-time DB & \yes & \yes & \yes & \yes & \yes \\
|
|
Auto REST API & \yes & \yes & \no & \no & \yes \\
|
|
GraphQL & \no & \no & \no & \yes & \yes \\
|
|
File storage & \yes & \yes & \yes & \no & \yes \\
|
|
Admin UI & \yes & \yes & \yes & \yes & \yes \\
|
|
Multi-tenant & \yes & \pmark & \no & \yes & \pmark \\
|
|
IAM-native & \yes & \no & \no & \no & \no \\
|
|
Self-hosted & \yes & \yes & \no & \yes & \yes \\
|
|
Open source & \yes & \yes & \no & \yes & \yes \\
|
|
Goja VM & \yes & \no & \no & \no & \no \\
|
|
SQLite mode & \yes & \no & \no & \no & \no \\
|
|
K8s CRD & \yes & \no & \no & \no & \no \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\subsection{Performance}
|
|
|
|
Benchmarked on a single 2-vCPU node (SQLite mode, 1000 records, 100 concurrent connections):
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\caption{CRUD operation latency (median, milliseconds).}
|
|
\footnotesize
|
|
\begin{tabular}{@{}lrrrr@{}}
|
|
\toprule
|
|
System & Create & Read & Update & Delete \\
|
|
\midrule
|
|
Hanzo Base & 0.8 & 0.3 & 0.7 & 0.5 \\
|
|
Supabase & 3.2 & 1.1 & 2.8 & 2.1 \\
|
|
Firebase & 12.0 & 4.5 & 11.0 & 8.0 \\
|
|
Hasura & 2.5 & 0.9 & 2.2 & 1.8 \\
|
|
Appwrite & 4.1 & 1.5 & 3.6 & 2.9 \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
Hanzo Base in SQLite mode achieves sub-millisecond reads because the database is embedded in the same process with zero network overhead. PostgreSQL mode adds approximately 1--2ms per operation for network round-trip. Supabase and Hasura require separate PostgreSQL instances, contributing to their higher latencies.
|
|
|
|
\subsection{Integration Cost}
|
|
|
|
Deploying a new Hanzo Base instance with IAM authentication, multi-tenant isolation, and S3-compatible storage requires 12 lines of Kubernetes YAML (one \texttt{HanzoBase} CRD). The equivalent Supabase deployment requires 4 separate services (PostgreSQL, GoTrue, PostgREST, and Storage), each with independent configuration.
|
|
|
|
\subsection{Key Differentiator}
|
|
|
|
The embedded Goja JavaScript VM enables server-side hooks, computed fields, and custom endpoints without deploying additional services. Combined with native IAM integration, Hanzo Base replaces what would otherwise be Supabase + Auth0 + a custom Node.js service for business logic.
|
|
|
|
%% ============================================================================
|