Forem: Farhan Syah

What Kind of Database I Want NodeDB to Be

Farhan Syah — Fri, 03 Apr 2026 08:19:35 +0000

When I think about NodeDB, I am not thinking about the longest feature list or the flashiest demo.

I am thinking about a database I can trust before and after an application grows.

In the long run, I want NodeDB to be easy to use, reliable in different scenarios, and secure enough that I do not have to keep second-guessing it. I want it to be something I can start with early, keep using later, and not feel forced to replace once the project becomes more serious.

I should not have to rethink the whole stack every time product requirements change. I should not have to move data somewhere else just because a new use case shows up. I should not have to accept that one part of the database is “real” while another important part is just a workaround. If the business grows, the database should still feel like a stable base, not the next reason to re-architect.

But that is far in the future. The current reality is simpler: I am still building toward it.

Right now, my main concern is not polish. It is not making NodeDB look finished before it is finished. It is the foundation.

I want to build enough core capability early, and build it deeply enough, that I do not spend the next few years patching around missing pieces.

Many databases grow by accumulation. A feature becomes important, so it gets added. Another workload appears, so another layer gets introduced. Then another extension, another plugin, another wrapper, another sidecar. Over time, the system may cover more ground, but it does not always become more coherent.

From the user side, that has a cost. Query behavior becomes uneven. Operational expectations stop being consistent. One feature feels mature, another feels awkward, another works only if you accept a few strange rules. At that point, you are not really using one clean system anymore. You are managing the boundaries between several pieces that happen to live near each other.

That is one of the reasons PostgreSQL started feeling heavy for me across multiple projects.

PostgreSQL is good. Its ecosystem is strong. I am not arguing otherwise. But extensions do not magically become one deeply integrated system just because they run around the same database core. In practice, the burden shifts to the user. You are the one stitching capabilities together, working around different limitations, and dealing with the gaps between them.

I have seen a similar pattern in databases that try to unify more from the start.

SurrealDB has a vision I understand. But my concern is the same: I do not want a database to keep piling things on top if the foundation was not designed to carry them well. Systems should evolve, of course. That is normal. But there is still a difference between growing a system and collecting features.

That difference shows up in the user experience very quickly. Some capabilities exist, but they still feel second-class. The ergonomics are weaker. The query model is thinner. Performance is less predictable. Operations feel awkward. The feature works in a demo, but once it becomes central to a real workload, you start seeing the limits.

That is exactly what I want to avoid with NodeDB.

I want NodeDB to reduce re-architecture later instead of causing it. I do not want to reach the next stage of a product and realize that an important capability was treated as an afterthought, so now the stack has to be rearranged. I do not want core requirements to arrive later and collide with a design that was never meant to support them properly.

That is why I care so much about feature depth early.

Not because users need everything on day one. And not because I think I can build everything perfectly from the start. I cannot.

What I do believe is this: if an important capability is likely to matter sooner or later, I would rather think hard about how it belongs in the system early.

I am not interested in a product page that lists many features. I care about whether the database actually behaves like one cohesive system. I care about whether the features feel like they belong together. I care about whether it stays usable across different scenarios without pushing the user into constant redesign or workaround.

If a database claims to do everything, but half the capabilities feel weak, awkward, or fragile, that is not real completeness. I would rather build something deeper but longer than wider and shallower.

So the database needs to be dependable. It has to hold up when requirements expand. It has to help the user avoid unnecessary stack changes later.

Maybe this approach is wrong in some places. It is still my opinion, my bias, and my way of thinking through the problem.

But if NodeDB works, I want it to work in a way that still makes sense years later, not just in the first exciting demo.

In the next post, I will go deeper into the design direction behind that idea and why so many multi-model databases still feel wrong to me.

Repo: NodeDB

Why I'm Building NodeDB

Farhan Syah — Thu, 02 Apr 2026 21:26:16 +0000

For the last few years, PostgreSQL has been my default database.

Before that, I worked with MySQL, MariaDB, and MongoDB. But once I spent enough time with PostgreSQL, it became very hard to justify anything else for most projects. It gave me the relational model I wanted, plus JSON support that was good enough to remove a lot of my reasons for using MongoDB. When I needed spatial support, I could add PostGIS. When I needed time series and partitioning, I could use TimescaleDB. For a long time, that worked very well.

Then the workload started changing.

Over the last two years, AI and ML stopped being side concerns and started becoming part of real application requirements. That meant vector search became relevant. PostgreSQL still looked like the right answer because pgvector existed and, at first, it was good enough. But once I started using it across more serious workloads, I kept running into the same friction: scaling and performance concerns, filtering limitations, and dimension and storage constraints that mattered for my use cases at the time.

And vector was only one part of the problem.

Then came graph needs. At that point, the pattern became very familiar. I could keep stretching PostgreSQL. I could handle graph logic manually at the application level. I could try more extensions. I could wire more tools together. And yes, any one of those decisions can be justified if you are working on one project and you are willing to absorb the complexity.

But I am not working on one project.

I work on multiple projects every year, often with different requirements. That changes the economics completely. What looks reasonable in isolation turns into repeated operational and mental overhead when you keep doing it again and again. A couple of extensions are fine. Then you need another one. Then another workaround. Then another set of limitations, quirks, and edge cases to remember. Then offline-first and sync requirements enter the picture and now you are adding even more surrounding tools just to make the whole thing usable.

That was the real breaking point for me.

The problem was not that PostgreSQL stopped being good. The problem was that PostgreSQL plus extensions plus surrounding infrastructure started becoming a stack I had to keep rebuilding across projects. It worked, but the repetition was exhausting.

I started looking around.

Like many people in this space, I first looked at what already existed. If someone had already built the thing I wanted, I would rather use it than build a database from scratch.

I found SurrealDB. I liked the vision. I still think the direction is compelling: fewer hops, better developer experience, a more unified model. But when I looked deeper, especially at the implementation and tradeoffs, I was not convinced. From my perspective, it felt more like a patchwork than a database designed deeply from the ground up. Even in graph support, I did not find the level of capability I expected. The idea was attractive. The execution did not give me enough confidence.

Then I looked at ArcadeDB. In many ways, I thought it was stronger. Better coding quality, better performance characteristics, more substance. But it is JVM-based, and I wanted something smaller, tighter, and better suited to the kinds of embedded, mobile, offline-first, and mixed deployment scenarios I care about.

At that point, my realistic options looked like this:

Stick with PostgreSQL and keep stacking extensions. Work around another database that did not fully fit. Or accept a polyglot architecture and keep paying the integration cost.

None of those felt right to me.

So I chose a fourth option: build my own database.

That is how NodeDB started in 2025.

It started as a side project, and honestly, I did not have high expectations. If it worked, it worked. If it failed, it failed. That attitude was useful because this is not the kind of project you begin with false confidence.

I have already scrapped the project twice.

This current version is the third serious attempt, and I only started building it earlier this year. The first two failures were important. They forced me to understand what I was doing wrong, what I was hand-waving, and what needed to be designed properly from the beginning instead of patched later. I do not think I would have reached this version without those failures.

One thing I should mention briefly: I use AI heavily in the implementation.

The code is mostly written by AI, not by me typing everything manually. That is simply the practical reality. It writes faster than I do, and often better than I do at raw throughput. But I am still the one directing, reviewing, rejecting, and understanding it. That part matters to me. If I am going to build a database seriously and support it in the future, I need to understand it all the way down.

NodeDB exists because I wanted something I could actually use across real projects without rebuilding the same database stack every time.

I built it first to solve my own use cases, because that part is non-negotiable. If it does not solve my real problems, there is no point. But I also do not want to build a shallow personal tool that only works for me. I want to go deeper than that. I want something that can support broader use cases properly, with serious performance, serious design, and serious technical depth.

Right now, NodeDB is working for my use cases, but it is still evolving.

I have already tested it in pilot projects, and for the kinds of problems I built it to solve, it is starting to prove itself. That does not mean the journey is done. Far from it. A database only becomes real when the design holds under pressure, when the tradeoffs are honest, and when the implementation can stand up over time.

That is the challenge I have chosen.

Will I make it? Time will tell.

But this is the journey I am on, and I am going to share it openly: the design decisions, the mistakes, the database ideas, the tradeoffs, and the lessons I learn along the way.

If you care about database engineering, multi-model systems, offline-first architecture, or the hard tradeoffs behind building a database from scratch, follow this journey.

I will be sharing what works, what fails, what I have to redesign, and what I learn from trying to make NodeDB real.

If that sounds interesting, follow me here on dev.to and keep an eye on the next posts. I am just getting started.

Repo: NodeDB

numr 0.5.0: The Rust numerical computing library that doesn't make you choose

Farhan Syah — Sat, 14 Mar 2026 20:15:39 +0000

Last year, I started building numr because I was frustrated.

ml-rust / numr

A high-performance numerical computing library for Rust with GPU acceleration, inspired by Numpy

numr

Foundational numerical computing for Rust

numr provides n-dimensional tensors, linear algebra, FFT, statistics, and automatic differentiation—with native GPU acceleration across CPU, CUDA, and WebGPU backends.

numr is like Numpy in Rust but built with gradients, GPUs, and modern dtypes built-in from day one.

What numr Is

A foundation library - Mathematical building blocks for higher-level libraries and applications.

numr IS	numr is NOT
Tensor library (like NumPy's ndarray)	A deep learning framework
Linear algebra (decompositions, solvers)	A high-level ML API
FFT, statistics, random distributions	Domain-specific
Native GPU (CUDA + WebGPU) + autograd

For SciPy-equivalent functionality (optimization, ODE, interpolation, signal), see solvr.

Why numr?

vs NumPy

Capability	NumPy	numr
N-dimensional tensors	✓	✓
Linear algebra, FFT, stats	✓	✓
Automatic differentiation	✗ Need JAX/PyTorch	✓ Built-in `numr::autograd`
GPU acceleration	✗ Need CuPy/JAX	✓ Native CUDA + WebGPU
Non-NVIDIA GPUs	✗ None	✓ AMD, Intel, Apple via WebGPU
FP8 /

…

View on GitHub

I wanted to do numerical computing in Rust — tensors, linear algebra, FFT, gradients — on GPUs. Not just NVIDIA GPUs. Any GPU. And I didn't want to glue together five incompatible crates to do it.

Python didn't plan for this either. NumPy emerged organically, and it took years of bolting on CuPy, JAX, and PyTorch before Python had GPU compute and autograd — scattered across incompatible libraries.

Some people say fragmentation is fine. Separate crates for separate concerns — that's the Unix philosophy. And I'd agree, if they shared conventions, types, and backends. But they don't. ndarray gives you tensors but no GPU. nalgebra gives you linear algebra but no autograd. rustfft gives you FFT but nothing else. Different types, different idioms, none of them compose.

So the burden falls on you — the application developer. You're the one writing adapter layers between crates. You're the one figuring out why this tensor type doesn't work with that decomposition. And when you need GPU support or a missing operation? You're filing issues and PRs upstream, waiting for maintainers, before you can get back to building your actual application.

numr takes that burden off you. One library, one tensor type, one API — tensors, linalg, FFT, statistics, autograd, GPU. numr will handle the hard part. You can just focus on building your application.

one library, one API, every backend. Write your code once. Run it on CPU with AVX-512. Run it on NVIDIA with native CUDA kernels. Run it on AMD, Intel, or Apple silicon through WebGPU. Same code. Same results.

Today, numr 0.5.0 ships. And it's the release where it stopped being a "promising project" and became something you can actually build on.

What changed

Fused kernels — because memory bandwidth is the real bottleneck

The single biggest performance win in GPU computing isn't faster math. It's reading memory fewer times.

A naive softmax reads your tensor five times: max, subtract, exp, sum, divide. A fused softmax reads it once. For large tensors, that's not a 5x difference (the math is cheap), but it's easily 2-3x.

0.5.0 adds fused kernels for the operations that matter most:

GEMM epilogue: matmul + bias + activation in one kernel launch. This is the inner loop of every neural network. Forward and backward.
Activation-mul: for gated architectures like SwiGLU that power modern LLMs. One read instead of three.
Add-norm: residual connection + normalization fused together. The other operation you hit every single transformer layer.

All of these work on CPU, CUDA, and WebGPU. All of them have backward passes for autograd.

FP8 and quantized compute — because not everything needs 32 bits

FP8 isn't just "smaller numbers." It's the difference between fitting a model in VRAM or not. Between one GPU and two.

numr now does FP8 matrix multiplication natively — E4M3 and E5M2 formats, across all backends. No external libraries. No NVIDIA-only restrictions.

We also added i8×i8→i32 quantized matmul on CPU. This is what powers efficient quantized inference when you don't have a GPU.

2:4 structured sparsity — because half your weights are probably zero

NVIDIA's Ampere architecture introduced hardware support for 2:4 sparsity: for every group of 4 weights, exactly 2 are zero. The hardware skips them, doubling throughput for free.

numr 0.5.0 supports 2:4 structured sparsity across all backends. On CUDA, it hits the hardware fast path. On CPU and WebGPU, it uses optimized sparse kernels.

Autograd that actually covers what you need

Previous releases had autograd for basic operations. 0.5.0 makes it comprehensive:

conv1d, conv2d, softmax, rms_norm, layer_norm, SiLU, softplus, SwiGLU, dropout, the fused GEMM epilogue, fused add-norm, dtype cast, narrow, cat, gather — all differentiable, all with correct backward passes, all supporting second-order derivatives.

Activation checkpointing lets you trade compute for memory. Backward hooks let you trigger distributed gradient sync during backprop.

This isn't an ML framework. It's the autograd engine that ML frameworks build on.

A CUDA backend that acts like it belongs there

The CUDA story got serious in 0.5.0:

Caching allocator. CUDA memory allocation is expensive. The old approach (stream-ordered allocation) worked but left performance on the table. The new Rust-side caching allocator reuses memory blocks, cutting allocation overhead dramatically.

Graph capture. Record a sequence of kernel launches once, replay it with zero overhead. Essential for inference serving where you run the same computation thousands of times.

GEMV fast paths. When one matrix dimension is small (which happens constantly during inference — batch size 1), you don't want full tiled GEMM. Specialized GEMV kernels for transposed weight matrices avoid unnecessary work.

Pipelined D2H copy. Overlap GPU computation with data transfer back to the host. The GPU doesn't wait for the CPU, the CPU doesn't wait for the GPU.

Why 0.5.0 matters

This is where numr crosses the threshold from "interesting foundation" to "you can build real things on this." And we know because we did.

0.5.0 has been validated against real downstream consumers. solvr — a scientific computing library with optimization, ODE solvers, and interpolation — builds and runs on numr 0.5.0. boostr — an ML framework with attention, MoE, and Mamba blocks — builds and runs on it too. LLM inference and embedding generation work end-to-end.

This isn't a library that passes unit tests in isolation. It's a library that other libraries are built on, and those libraries work.

The fused kernels mean you're not leaving performance on the table. The autograd coverage means you can differentiate through realistic computation graphs. The CUDA infrastructure means GPU workloads actually perform. And all of it works the same across CPU, CUDA, and WebGPU.

What's next

0.5.0 unblocks new releases of solvr (scientific computing — optimization, ODE solvers, interpolation) and boostr (ML framework) which both build on numr.

For numr itself, 0.6.0 focuses on hardening: cleaning up error handling, API stability audit, and preparing for an eventual 1.0.

ROCm (native AMD GPU) is on the roadmap for 0.7.0+.

Try it

[dependencies]
numr = "0.5.0"

# With GPU support
numr = { version = "0.5.0", features = ["cuda"] }
numr = { version = "0.5.0", features = ["wgpu"] }

GitHub: github.com/ml-rust/numr
Crates.io: crates.io/crates/numr

numr is Apache-2.0 licensed. Contributions welcome.

[Boost]

Farhan Syah — Wed, 11 Mar 2026 20:32:38 +0000

Why I Built RDX: Bringing Modern "Docs-as-Code" to the Rust Ecosystem

Farhan Syah ・ Mar 11

#ai #webdev #programming #rust

Why I Built RDX: Bringing Modern "Docs-as-Code" to the Rust Ecosystem

Farhan Syah — Wed, 11 Mar 2026 20:22:11 +0000

For more than 10 years, I lived and breathed the Node.js ecosystem. I built applications using Node, Bun, and especially Svelte. I loved it. I still do—I’ve never been of the opinion that JavaScript or Node.js is "bad." Tools like Astro, MDX, and SvelteKit are genuinely phenomenal.

But a while ago, my work shifted. I needed more control at a lower level, which led me to Rust. I’ve been using Rust full-time for a while now, and honestly? I don’t plan on going back.

However, moving to a new ecosystem always exposes what’s missing. In Rust, one of the biggest glaring holes is public-facing documentation tooling.

Don't get me wrong: rustdoc and docs.rs are incredible. They are arguably the cleanest, best ways to document source code in the industry. But API documentation isn't product documentation. When you need to build public-facing docs—with rich tutorials, interactive API playgrounds, custom callouts, and interactive tabs—Rust falls short.

You usually end up using mdBook, which is great but visually basic. If you want a modern, interactive documentation site that rivals Stripe or Vercel, you are forced to leave Rust and go back to Python (MkDocs) or the Node.js ecosystem (Docusaurus, Mintlify, Nextra).

I wanted to keep my stack 100% Rust. I didn't want to maintain a package.json just to write my documentation.

I decided to build my own Static Site Generator (SSG) in Rust that runs on WebAssembly (WASM) to fully utilize Rust in the browser. But right out of the gate, I hit a massive blocker: the format.

The MDX and Markdoc Dilemma

Standard Markdown (.md) is too limited. You can't build rich, interactive UI components with it.

The industry standard is MDX. But MDX is tightly coupled to JavaScript. It is inherently imperative—it executes code. Trying to force a Rust backend to safely parse, execute, and render React-based MDX is a nightmare.

Then there is Markdoc (by Stripe). Markdoc gets the philosophy exactly right: documents shouldn't execute code; they should be declarative data. But Markdoc is written entirely in TypeScript/JavaScript. Writing a Rust wrapper around a JS library, or trying to port a massive, moving TS codebase to Rust, felt counter-productive.

I needed a native, high-performance implementation written in Rust.

Introducing RDX: Reactive Document eXpressions

I realized that before I could build the generator, I needed the language. So, I designed RDX.

RDX has everything standard Markdown has, but it supports strict, declarative component rendering. It uses the familiar HTML/JSX-like syntax (<Notice type="warning">) that authors are used to, but it fundamentally treats documents as pure data. No import statements, no JavaScript execution. Just a clean, strictly typed Abstract Syntax Tree (AST).

I didn't just want to build a Rust crate, though. I started by writing a proper, formal specification. I did this so that while I was building the official Rust implementation, anyone else could read the spec and build an RDX parser in Go, Python, or Zig tomorrow.

After finalizing the spec, I built the official tools. Today, I'm thrilled to release them:

rdx-parser: The core parsing engine built on top of pulldown-cmark.
rdx-ast: The strictly typed data structures.
rdx-schema: A validation engine that guarantees your authors don't use fake props or components.
I've even included a CLI tool to help people convert their existing MDX files to RDX, verify schemas, and more.

Everything is open-sourced, and an be viewed here:

rdx-lang · GitHub

rdx-lang has 4 repositories available. Follow their code on GitHub.

github.com

You can start writing RDX today. In fact, I've already built and published a VS Code/VSCodium extension for syntax highlighting to make authoring a breeze.

The Missing Piece: Rendering (And a Sneak Peek)

Right now, we have the parser, the AST, and the editor support. The only thing missing is the rendering software to turn these .rdx files into a beautiful website.

Don't worry, I'm building that right now.

I am currently developing a next-generation SSG. It will consume your RDX files and generate a documentation site that rivals Docusaurus, Mintlify, and MkDocs. The best part? It uses Rust and WASM to deliver high speed build times and interactive components without ever touching npm.

Built for the AI Era

There is one final reason I believe RDX is the future of "Docs as Code."

RDX is incredibly AI-friendly. If you ask an LLM to write MDX, it frequently hallucinates JavaScript imports or breaks the build with syntax errors. If you ask an LLM to write Markdoc, it struggles with the custom Liquid-style tags.

But LLMs excel at writing standard HTML tags with typed attributes. Because RDX isolates components as pure data and pairs them with rdx-schema validation, you can autonomously generate documentation via AI and validate it instantly at build time. An RDX-powered AI documentation pipeline will beat an MDX or Markdoc pipeline in stability every single time.

But, it will only be like that if everything is done correctly, and I get all the support from the community.

I hope RDX can become the new standard for documentation. We finally have a way to write rich, interactive content without sacrificing the safety, speed, and tooling of the Rust ecosystem.

Check out the repo, read the spec, and stay tuned. The renderer is coming next.