DEV Community: Esteban Fuster Pozzi

From Babylon.js to Native WebGPU: How OVGrid Migrated to a Framework-Free Engine

Esteban Fuster Pozzi — Tue, 17 Feb 2026 17:43:37 +0000

In 2020, OVGrid started as an experiment in building dynamic 3D virtual worlds using Babylon.js — one of the most mature WebGL frameworks available. We explored terraforming, dynamic textures, height maps, and real-time rendering. The results were promising.

OVGrid's first 3D environment tests with Babylon.js (2020)

Early terrain generation and texture mapping experiments

%[https://www.youtube.com/watch?v=_hfYsrHMAeI]

Babylon.js gave us a solid foundation: a scene graph, a physics engine, material system, and a large community. For a prototype, it was the right choice. But as OVGrid's ambitions grew — planetary-scale terrain, atmospheric scattering, thousands of instanced objects — the framework started showing its limits.

Why We Left Babylon.js

Babylon.js is an excellent framework. It even added WebGPU support. So why leave?

The answer isn't about Babylon.js being bad. It's about what happens when you need total control over every GPU instruction.

Bundle Size and Dependencies

A full Babylon.js build adds significant weight to your application. For a project that targets instant browser access with zero downloads, every kilobyte matters. OVGrid needed to be lean — a PWA that loads in seconds, even on mobile.

GPU Pipeline Control

When you're writing custom atmospheric scattering shaders, cascaded shadow maps with 4 layers, and GPU-driven terrain instancing, you need direct access to the WebGPU pipeline. Working through a framework's abstraction layer means fighting against it when your needs diverge from its assumptions.

The Abstraction Tax

Every abstraction has a cost. Babylon.js manages its own render loop, its own resource lifecycle, its own state. When you need a Floating Origin system that keeps the camera at (0,0,0) and offsets the entire world in Float64 — or when you need to reduce terrain draw calls to one single call per frame — you need the GPU to do exactly what you tell it. No middleware.

Philosophy: Pure JavaScript, Zero Frameworks

OVGrid's philosophy aligns with a broader conviction: the best code is the code you fully understand and control. No framework updates breaking your build. No dependency chains. No black boxes. Just JavaScript, WGSL shaders, and the WebGPU API.

The Migration

The transition wasn't a weekend refactor. It was a deliberate, incremental process.

Phase 1 — Custom Render Pipeline. We replaced Babylon.js's render loop with a direct WebGPU pipeline. This alone gave us the ability to control exactly which compute and render passes execute per frame.

Phase 2 — Shader Rewrite. Every shader was rewritten in WGSL from scratch. Atmospheric scattering, terrain rendering, vegetation instancing — all hand-tuned for OVGrid's specific needs. No generic material system overhead.

Phase 3 — Floating Origin. The camera stays at (0,0,0) in GPU space. World coordinates use Float64 on the CPU, and only relative offsets are sent to the GPU. This eliminates the floating-point jitter that plagues every large-scale WebGL application.

Phase 4 — GPU-Driven Instancing. Terrain chunks, vegetation, and objects are rendered with a single instanced draw call per category. The GPU decides visibility, LOD, and placement.

Phase 5 — Modular Architecture. Using Bun as the bundler, we split the UI into lazy-loaded modules. Configuration panels load on first interaction. The main bundle stays minimal.

The Results

The numbers speak for themselves:

120 FPS sustained during planetary traversal — from ground level to orbit
One draw call for all terrain chunks per frame
Sub-second initial page load as a PWA
Zero dependencies — no node_modules, no framework updates, no breaking changes
Full mobile support — the same codebase runs on desktop and mobile browsers with WebGPU

When Frameworks Make Sense

This isn't an anti-framework manifesto. Babylon.js is the right choice for many projects — games, product configurators, architectural visualization. If your project fits within a framework's model, use it.

But when you're building a planetary-scale virtual world that needs to push every boundary of what the browser can do, the framework becomes the ceiling. Removing it becomes the unlock.

What's Next

OVGrid continues to evolve. The migration to native WebGPU was the foundation. On top of it, we're building:

GenosDB integration for P2P identity and real-time world state
Polygon blockchain for OVG tokens and ERC-1155 metaverse assets
Ready Player Me avatars for cross-platform identity
Cascaded Shadow Maps with 4-layer precision up to 10km

The browser is no longer the limitation. It's the platform.

Written by Esteban Fuster Pozzi (estebanrfp), creator of GenosDB and OVGrid.

Scaling the Metaverse: Building a Planetary-Scale Engine with WebGPU

Esteban Fuster Pozzi — Tue, 17 Feb 2026 16:37:58 +0000

How OVGrid is pushing the boundaries of the mobile and desktop web with deep modularization, blockchain integration, and high-precision rendering.

In the rapidly evolving landscape of web-based graphics, the leap from WebGL to WebGPU isn't just an upgrade — it's a paradigm shift. Today, I'm thrilled to share a deep dive into OVGrid, a project designed to prove that the browser can handle massive, planetary-scale environments with the fidelity and performance of native applications.

The Objective: Zero-Latency Exploration

The goal of OVGrid was simple yet ambitious: to create a seamless planetary traversal experience. Whether you are walking on the grass of a procedurally generated biome or orbiting at 500km altitude, the transition should be fluid, and the performance should remain at a solid 120 FPS.

To achieve this, we've implemented an architecture that prioritizes the "Single Source of Truth" rule:

CPU (JavaScript): Decides what exists. It handles the high-precision world coordinates (Float64), Level of Detail (LOD) logic, and physics state.
GPU (WGSL): Decides how it looks. It handles the heavy lifting of ray-tracing, atmospheric scattering, and instanced geometry.

Deep Modularization: The Phase 6 Milestone

Our latest engineering milestone, Phase 6: Granular UI Lazy Loading, addresses one of the most significant challenges in web apps: the initial payload.

By splitting our monolithic UI into independent modules — such as EnvironmentUI and TerrainUI — we've achieved a state where the browser only downloads and executes the code you actually use.

Using Bun as our bundler, we've reduced the main bundle size significantly. Now, configuration panels are triggered by fast keyboard shortcuts (T for Terrain, V for Environment), loading their specific HTML and logic only on first interaction. This "pay-as-you-go" script execution ensures that the experience remains snappy from the first second of the page load.

Engineering the Planet

At the core of the visual experience is a high-precision Floating Origin system. By keeping the camera at (0,0,0) in the shader and passing only relative offsets, we eliminate the floating-point "jitter" that typically plagues large-scale environments.

Other key technical pillars include:

Cascaded Shadow Maps (CSM): 4-layer cascades that provide razor-sharp shadows for your avatar while covering terrain up to 10km away.
Nervland-style LOD Rings: An adaptive subdivision system that maintains a highly detailed central block while progressively simplifying the periphery.
GPU-Driven Instancing: We've reduced terrain draw calls from hundreds to one single call per frame, maximizing the efficiency of the WebGPU pipeline.

A Sovereign Economy

OVGrid isn't just a technical showcase; it's a foundation for a decentralized economy. We have successfully integrated:

Polygon Blockchain: Live connectivity to the Amoy testnet for OVG Tokens and ERC-1155 metaverse assets.
Digital Identity: Using GenosDB, we implement WebAuthn biometrics and BIP39 mnemonic recovery, giving users true ownership of their data.
Global Avatars: Full integration with Ready Player Me, allowing users to hot-swap their cross-game identities in real-time.

The Future of Web Graphics

The combination of WebGPU's raw power and modern JavaScript tools like Bun and GenosDB is opening doors that were previously closed to web developers. OVGrid is a testament to what is possible when you combine low-level optimization with a modular, scalable mindset.

The horizon is wider than ever.

Written by Esteban Fuster Pozzi (estebanrfp), creator of GenosDB and OVGrid.

OVGrid is an Open Virtual Grid Metaverse

Esteban Fuster Pozzi — Tue, 17 Feb 2026 16:37:42 +0000

The first true metaverse experience built in a decentralized and open virtual grid.

Explore the decentralized, infinitely scalable, browser-based metaverse built on WebXR and a peer-to-peer architecture.

"Metaverse" is the reigning buzzword in tech. It promises an immersive digital future, but much of the conversation is dominated by closed, centralized ecosystems that replicate the limitations of today's internet. They demand expensive hardware, impose unilateral rules, and are ultimately owned by a single entity.

But what if the future of the metaverse wasn't a walled garden, but an open, limitless universe?

Introducing OVGrid, the Open Virtual Grid — a project that reimagines the metaverse from the ground up. It's not just another platform; it's a decentralized ecosystem designed to be truly open, scalable, and accessible to everyone.

What is OVGrid and Why is it Different?

OVGrid is a distributed metaverse where users can create and share real-time experiences. The key difference lies in its fundamental architecture, which moves away from the traditional client-server model to fully embrace decentralization.

This isn't just a technical choice; it's a philosophy. We believe that users should be the true owners of their digital assets and their experiences.

The Technological Engine of OVGrid

To achieve this vision, OVGrid is built on a stack of disruptive technologies that set it apart from anything else on the market:

True Decentralization with GenosDB

At the heart of OVGrid lies GenosDB, an innovative graph database that enables true peer-to-peer (P2P) communication. Instead of connecting to a central server, each user (or node) connects directly with others within a parcel, forming a dynamic and resilient Cellular Mesh network. This means lower latency, greater privacy, and no central entity with the power to pull the plug on the world.

Infinite Scalability: Incremental Coordinates

Most virtual worlds have a finite map, creating artificial scarcity and limiting growth. OVGrid solves this with a revolutionary concept: incremental coordinates. This allows for a universe with infinite lands. The grid can expand organically without limits, offering boundless potential for creation, exploration, and the digital economy.

Universal Accessibility through WebXR

The biggest barrier to entry for the metaverse? Hardware and downloads. OVGrid eliminates this obstacle by being built on WebXR, the web standard for immersive experiences.

This means you can access OVGrid:

From any modern browser on your PC or Mac.
On standalone VR headsets (like Meta Quest) without needing a PC.
With no heavy downloads or installations. Just click a link, and you're in.

This accessibility makes it inherently social and shareable.

Resilience and Flexibility: Offline First and PWA

OVGrid is designed for the real world. Thanks to its "Offline First" architecture, you can continue to interact and create even if you lose your internet connection. Changes sync automatically when you're back online. Furthermore, it operates as a Progressive Web App (PWA), allowing you to "install" it to your desktop or mobile device for instant access, just like a native app.

What Can You Do in the Open Virtual Grid?

OVGrid's architecture unlocks a universe of possibilities:

True Digital Ownership: Buy, sell, and lease land and assets as NFTs, secured by a distributed system.
Immersive Events and Meetings: Host conferences, concerts, team meetings, or social hangouts in custom virtual spaces.
Training and Education: Create simulations and interactive learning environments that transcend physical barriers.
Digital Art and Galleries: Exhibit and trade digital art in immersive galleries where creators have full control.
Brand Engagement: Brands can build unique, interactive experiences to connect with their audiences in a completely new way.

The Future is an Open Grid

OVGrid is currently in the Pre-Alpha stage, laying the foundation for this ambitious project. We are not building another game or a closed social network. We are building the infrastructure for a truly open metaverse — a digital canvas for a global community of creators, developers, and dreamers to build the future of the internet.

The metaverse shouldn't be a product you consume, but a universe you co-create. And that universe begins with an Open Virtual Grid.

Written by Esteban Fuster Pozzi (estebanrfp), creator of GenosDB and OVGrid.

Summary of Progress in 2021 Working at OVGrid

Esteban Fuster Pozzi — Tue, 17 Feb 2026 16:36:53 +0000

Testing Multiuser Land Channel

%[https://www.youtube.com/watch?v=-zHgE82w5yQ]

In 2021, OVGrid made remarkable progress in developing its metaverse, enhancing the user experience and expanding available functionalities. New virtual reality features were implemented, improving interactivity and immersion. In addition, the platform's performance was optimized, and the capabilities for creating and customizing virtual environments were expanded. These achievements reflect OVGrid's commitment to innovation and leadership in the metaverse space.

Written by Esteban Fuster Pozzi (estebanrfp), creator of GenosDB and OVGrid.

OVGrid (Open Virtual Grid)

Esteban Fuster Pozzi — Tue, 17 Feb 2026 16:36:52 +0000

An Open, Decentralized Metaverse with Infinite Lands.

In recent years, metaverses have stopped being just a futuristic vision to become a key part of the digital ecosystem. Big names like Decentraland and other virtual worlds have dominated the space, but now comes OVGrid (Open Virtual Grid), a project that not only aims to compete, but to revolutionize the virtual experience.

OVGrid is more than a metaverse. It is an open and distributed space, created with pure JavaScript, offering infinite lands, true decentralization, and an experience optimized for WebXR directly in the browser. Below, we explore why OVGrid is a unique proposal that redefines the rules of the game.

The Heart of OVGrid: A Truly Unlimited Experience

Unlike many other metaverses that limit the extension of their digital lands, OVGrid introduces the concept of infinite lands. What does this mean? That there are no barriers or restrictions for creation, exploration, and expansion within the virtual world.

In OVGrid, any user can own, build, and inhabit a space without worrying about the limitations imposed by a finite land model or speculative markets. This democratizes access and allows creativity to flow without restrictions.

Decentralized Technology: The P2P Metaverse

While other projects depend on centralized servers to function, OVGrid adopts a completely decentralized approach, based on a peer-to-peer (P2P) model. This means that:

No central servers: The virtual world is not controlled by a centralized entity, but distributed among users.
Guaranteed resilience: Decentralization protects the metaverse from interruptions and problems associated with centralized servers.
Total freedom: Users have true control over their spaces and data within the virtual world.

OVGrid not only adopts decentralization as a philosophy, but makes it the core of its functioning.

WebXR Optimization: The Metaverse in Your Browser

One of the biggest challenges of current metaverses is accessibility. Many require complex installations, specialized equipment, or dedicated applications to function. OVGrid breaks with these limitations by being designed specifically for the browser, offering an optimized experience with WebXR.

Key benefits of WebXR in OVGrid:

Total accessibility: You do not need downloads or expensive hardware. A modern browser is all you need to explore OVGrid.
Exceptional performance: Thanks to pure JavaScript optimization, OVGrid offers impressive graphics and minimal loading times, even on mid-range devices.
Universal compatibility: It works perfectly on a wide variety of devices, from desktop computers to mobile phones and virtual reality headsets.

With OVGrid, the metaverse is literally one click away.

Shareable Coordinates: Connect Instantly

Each location within OVGrid has a unique coordinate that can be easily shared as a link. By clicking, anyone can instantly join the exact position in the metaverse, without complications or complex processes.

Imagine organizing a virtual meeting or showing your latest creation in OVGrid and simply sending a link for others to join. It is that easy and powerful.

Competing with Giants: Why OVGrid?

In a landscape where names like Decentraland lead, OVGrid stands out for its unique and disruptive approach:

Land model: Infinite lands vs. limited lands.
Decentralization: 100% P2P vs. partial.
Accessibility: Browser-based (WebXR) vs. requires installation.
Optimization: Smooth on modest devices vs. higher demands.
Sharing: Direct links to coordinates vs. limited.

OVGrid not only offers an alternative, but a better experience in terms of accessibility, freedom, and creative potential.

The Future of the Metaverse is OVGrid

In OVGrid, we believe that the metaverse should be a free, accessible, and infinite place. Our commitment to decentralization, technological optimization, and unlimited creativity allows us to offer a unique experience that empowers users.

Whether you want to build your own world, explore new frontiers, or simply connect with others, OVGrid has a space for you.

Written by Esteban Fuster Pozzi (estebanrfp), creator of GenosDB and OVGrid.

Building a P2P Collaborative Whiteboard with GenosDB in a Single HTML File

Esteban Fuster Pozzi — Tue, 17 Feb 2026 14:15:27 +0000

Build complex real-time apps without a backend. This collaborative whiteboard runs entirely peer-to-peer, powered by the simplicity of GenosDB.

GenosBoard is a feature-rich, real-time collaborative whiteboard designed to showcase the power and simplicity of GenosDB. It's a complete demonstration of how to build sophisticated, decentralized applications without writing a single line of backend code. All communication, data synchronization, and state persistence happens directly between browsers in a peer-to-peer network.

This isn't just a simple demo; it's a blueprint for the next generation of collaborative tools. The magic lies in GenosDB's hybrid communication model, which this application leverages perfectly:

Persistent State (db.put, db.map): Shapes created, moved, or deleted are saved to the graph database. This state is automatically synchronized across all peers and persists through page reloads, providing a reliable, shared source of truth.
Ephemeral Events (db.room.channel): High-frequency data like live cursor positions and in-progress drag movements are sent through a separate, lightweight messaging channel. This data is never written to the database, ensuring peak performance and preventing unnecessary storage writes.

Core Code

The entire P2P whiteboard works with just a few lines of GenosDB:

import { gdb } from "https://cdn.jsdelivr.net/npm/genosdb@latest/dist/index.min.js";

const db = await gdb("collab-board", { rtc: true });

// Persistent state — shapes sync across all peers and survive reloads
db.put({ type: "shape/circle", x: 200, y: 150, color: "#646cff", radius: 35 });

// Reactive rendering — UI updates automatically when any peer changes data
const { unsubscribe } = await db.map({ query: { type: { $regex: "^shape" } } }, ({ id, value, action }) => {
  if (action === "added" || action === "updated") shapes.set(id, value);
  if (action === "removed") shapes.delete(id);
  render();
});

// Ephemeral channels — high-frequency data without touching the database
const cursorChannel = db.room.channel("cursor-pos");
cursorChannel.on("message", (pos, peerId) => drawRemoteCursor(peerId, pos));

const dragChannel = db.room.channel("shape-drag");
dragChannel.on("message", (data) => updateShapePosition(data));

This hybrid model — persistent graph data combined with ephemeral real-time channels — is what makes GenosDB uniquely suited for collaborative applications. No WebSocket server, no Firebase, no backend at all.

Key Features

Real-Time Collaboration: Draw, drag, and delete shapes, and see changes from other users instantly.
Live Cursors: See where other connected users are pointing on the canvas.
Persistent State: Your drawings are automatically saved in the browser and will be there when you return.
Serverless P2P Architecture: No central server, no websockets to manage, no database hosting fees.
Modern & Responsive UI: A clean, beautiful interface that's a pleasure to use.
Zero Dependencies, Single File: The entire application runs from a single HTML file, demonstrating extreme portability and simplicity.

GenosDB Concepts Showcased

P2P Initialization: Setting up a room with gdb("room-name", { rtc: true }).
Reactive State Syncing: Using db.map() to reactively render the UI from database changes.
Atomic Operations: Modifying the shared state with db.put() and db.remove().
Ephemeral Messaging: Using db.room.channel() for high-frequency, non-persistent data.
Hybrid Data Strategy: The core architectural pattern of combining persistent and ephemeral communication for maximum efficiency.
Modern JavaScript Best Practices: Leveraging top-level await, object destructuring, and efficient event handling.

Build More with GenosDB

If this whiteboard inspires you, explore other real-time applications built with GenosDB:

Dive into the code to see just how few lines it takes to build something this powerful. Start building your own decentralized, real-time application today with GenosDB.

🔗 Try the Live Demo →

🔗 View Source Code →

This article is part of the official documentation of GenosDB (GDB).

GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

📚 Wiki | additional notes and guides

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

Gun: An Ecosystem of Tools for Distributed Applications

Esteban Fuster Pozzi — Tue, 17 Feb 2026 01:32:45 +0000

What Is GunDB?

GunDB (also known as Gun.js) is an open-source, real-time, distributed graph database written in JavaScript. Designed with an Offline-First approach and a keep-it-simple philosophy, it enables developers to build encrypted, community-run, peer-to-peer applications directly in the browser.

GunDB is used in production by Internet Archive and HackerNoon, and decentralized alternatives to platforms like Reddit, YouTube, and Wikipedia push terabytes of daily P2P traffic through the GUN network.

Key Features

Real-time data synchronization
Decentralized and distributed architecture with cryptographically secure data replication
Scalability without relying on central servers or a continuous internet connection

Default servers act as backup and propagation checkpoints. Among available adapters, you can use Amazon S3, among others.

When a client-side app (browser) requests data, it merges responses with its local state using a CRDT, then caches the result.

This means:

Next time, the data loads instantly — even offline.
Data is replicated across all browsers that requested it.
If your server goes down, data can still be recovered from other peers.

Losing important information becomes nearly impossible, since all copies would have to disappear simultaneously.

%[https://www.youtube.com/watch?v=b09pXG_wiVQ]

Core Concepts

Real-Time synchronization across peers
Distributed peer-to-peer architecture
Decentralized — no single point of failure
Offline-First with local state merge
Graph Database with CRDT conflict resolution
Radix Storage Engine (RAD)
Standalone JavaScript — no external dependencies
Small bundle size

SEA: Security, Encryption, and Authorization

GunDB's cryptographic layer is called SEA (Security, Encryption, Authorization). It provides:

User authentication with public/private key pairs generated via the Web Crypto API
Data signing — every write operation can be cryptographically signed by its author
Data encryption — end-to-end encryption between users using ECDH key exchange
Proof of work — optional computational proof for rate limiting

SEA is the foundation for building trusted, authenticated applications on top of GunDB. It uses browser-native cryptographic primitives (ECDSA for signing, ECDH for shared secrets, AES-GCM for encryption) rather than external libraries.

Known Limitations

GunDB has been in development for many years — a remarkable achievement for an open-source P2P project. But with that longevity comes accumulated technical debt, which is natural in any long-lived codebase. Some areas where this is most visible:

localStorage as default storage — The default persistence layer uses localStorage, a synchronous API with a ~5MB cap that blocks the main thread. Modern alternatives like OPFS and IndexedDB offer significantly better performance. The RAD (Radix) adapter improves this but adds complexity.
HAM conflict resolution — GunDB uses a Hypothetical Amnesia Machine based on wall-clock timestamps. In distributed systems, clock drift between devices can lead to unpredictable conflict resolution. Newer approaches like Hybrid Logical Clocks (HLC) solve this without relying on synchronized clocks.
Sync after extended disconnections — Prolonged offline periods can result in difficult-to-debug synchronization states, as there is no operation log to replay missed mutations. Without an oplog, there is no way to send only the delta of what changed.
Relay infrastructure — While GunDB is decentralized, it relies on relay servers for peer discovery and data propagation. The default public relays can become bottlenecks under heavy load.
Codebase complexity — Years of incremental development have resulted in a codebase that can be challenging for new contributors to navigate. This is a common pattern in projects that have evolved organically over a long period.

These are engineering trade-offs, not defects — every distributed system makes them. For projects that need different trade-offs (OPFS storage, hybrid delta sync, Cellular Mesh topology), next-generation alternatives like GenosDB were designed from scratch to address these specific challenges.

Plugins and Modules

Users (SEA) — Security, Encryption, Authorization
Storage adapters — file, LevelDB, RAD, and more
Integration — Vue.js, React, and community adapters

Gun Recommended Links

Beyond GunDB: The Next Generation

Inspired by the GunDB ecosystem, GenosDB was created to push P2P databases further — with a modular plugin architecture, zero-trust security model with RBAC, Cellular Mesh networking for scalability, and OPFS-based persistent storage. If you're building decentralized applications and want a modern, actively maintained alternative, explore GenosDB.

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

📚 Wiki | additional notes and guides

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

GenosDB: Distributed Graph-Based Database

Esteban Fuster Pozzi — Tue, 17 Feb 2026 00:43:32 +0000

In modern web development, we’ve reached an inflection point. Users demand experiences that are fast, collaborative, and work offline, but traditional architectures built on centralized servers have become a bottleneck. Synchronizing state between multiple users in real-time is complex, expensive, and fragile.What if we could remove the central server from the equation?GenosDB isn’t just another database; it’s a fundamental answer to this challenge. It’s a P2P, local-first, distributed graph database designed from the ground up to empower developers to build the next generation of web applications: systems that are inherently collaborative, secure, and resilient.In this article, we’ll explore how GenosDB’s unique architecture solves some of the most difficult problems in real-time development.

From Manual Syncing to an Automatic Dataflow

One of the biggest headaches in collaborative applications is state management. How do you ensure that when one user drags a card on a Kanban board, every other user sees the change instantly?GenosDB solves this natively:- Real-time P2P Synchronization: Using GenosRTC (a layer on top of WebRTC), any data change on one device is intelligently and automatically propagated to all other connected peers. You don’t need to set up WebSockets, manage reconnections, or write complex sync logic. It just works.- Cross-Tab Consistency: Thanks to BroadcastChannel, if a user has your application open in multiple tabs, the state remains perfectly synchronized between them with no extra effort.

Your Application, Always Available: Local-First Persistence

What happens if a user loses their internet connection? With a traditional architecture, the application stops working. With GenosDB’s local-first approach, the experience is seamless:- Browser Storage with OPFS: GenosDB utilizes the Origin Private File System (OPFS), a fast and persistent storage space directly in the browser. The application always reads and writes locally, which makes it incredibly fast.- Native Offline Support: Users can continue to work, create, and modify data while offline. As soon as the connection is restored, GenosDB automatically handles syncing the changes with the network.All of this is managed efficiently, using MessagePack for serialization and Pako compression to keep storage usage to a minimum.

Modeling the Real World: The Power of the Graph

Real-world applications aren’t just simple tables and rows; they are networks of interconnected data. A user belongs to a team, a task is assigned to a user, a document is linked to another.GenosDB embraces this reality with its graph data model. Instead of forcing your data into rigid structures, you can naturally model entities (nodes) and the relationships (links) between them. This is crucial for social applications, content management systems, and of course, virtual worlds like OVGrid.

Security in a Serverless World: The SM + RBAC Module

Decentralization introduces a critical question: if there’s no central server, who controls permissions? How do we prevent a malicious actor from deleting everyone’s data?This is where GenosDB’s Security Manager (SM) with Role-Based Access Control (RBAC) becomes a revolutionary feature:- Cryptographic Identity: Every user owns their identity, secured with modern cryptography through WebAuthn (passkeys, biometrics). No more passwords.- Signed Operations: Every write operation (put, link, remove) is digitally signed. The network doesn’t trust; it verifies.- Flexible Role Hierarchy: You can define roles like superadmin, admin, manager, or guest and assign granular permissions (read, write, delete). A guest cannot write data, and a manager cannot delete an admin’s work. These rules are enforced in a distributed manner by every peer on the network.This zero-trust system allows you to build complex and secure P2P applications where permissions and governance are woven into the very fabric of the database.

Conclusion: Start Building the Future, Today

GenosDB is more than a collection of features; it’s a cohesive platform designed for a new paradigm of web applications. Whether you’re building a collaborative tool, a decentralized social network, an app that needs to work offline, or simply want a simpler way to manage real-time state, GenosDB provides the foundation you need.

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

📚 Wiki | additional notes and guides

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

GenosDB: Distributed Graph Database with Module Support

Esteban Fuster Pozzi — Tue, 17 Feb 2026 00:42:35 +0000

Distributed Graph Databases with AI and Geospatial Query Support Modules

In the fast-paced world of web development, the ability to manage data efficiently, in real time, and in a distributed manner is more crucial than ever. GenosDB emerges as an innovative solution — not only due to its robust foundation as a client-side P2P graph database — but also because of its inherently modular and extensible architecture. Today, we explore how this modularity unlocks a new paradigm of possibilities by integrating artificial intelligence directly into its core.

The Solid Foundations of GenosDB

Before diving into its modular extensions, let’s recall the core features that make GenosDB a powerful platform:- Real-Time P2P Synchronization: Using WebRTC (via GenosRTC internal module) and BroadcastChannel, GenosDB allows automatic data sync across multiple peers and browser tabs without a central server.- Conflict-Free Consistency: Powered by Hybrid Logical Clocks (HLC) and a Last-Write-Wins (LWW) conflict resolution strategy, ensuring data convergence even under concurrent operations.- Advanced Client-Side Persistence: Leverages Origin Private File System (OPFS) for efficient storage with fallback to IndexedDB, all managed asynchronously in Web Workers to avoid blocking the main thread.- Optimal Efficiency: Uses MessagePack for binary serialization and Pako (zlib) for compression, minimizing bandwidth and storage usage.

The Power of Modularity: A Growing Ecosystem

The true magic of GenosDB lies in its design, which allows clean and decoupled injection of new features and operators. This is especially evident in its dynamic query and data processing capabilities.

1. A Dynamic and Extensible Query System .map()

The core of data interaction in GenosDB is its .map() method. It’s not just for retrieving data; it’s a live interface supporting:- Rich and Familiar Operators: A built-in set of operators ($eq, $ne, $gt, $gte, $lt, $lte, $in, $between, $exists, $text, $like, $regex) enables precise filtering.- Complex Logical Queries: Use of $and, $or, and $not allows building advanced logical conditions, applied recursively via createFilter.- Access to Nested Fields: With getNestedValue, it’s possible to query and sort by deeply nested fields within node value objects (e.g., user.address.city).- Pagination & Sorting: Full control over results with $limit, $after, $before, and order (asc / desc) on any field.- Real-Time Updates: By providing a callback function, .map() becomes reactive — emitting initial, added, updated, and removed events, essential for dynamic UIs.

2. Smart Integration: AI-Powered Data

GenosDB enhances data handling with natural language queries that integrate seamlessly into the query flow.

NL-Enhanced Data Processing

How it works: The GenosDB instance is wrapped. When using .map(), a prompt option can be passed.The Process:- GenosDB filters nodes using standard operators.- The value of the resulting nodes, along with the user prompt.- The AI is instructed to modify fields within the value objects and return a JSON array with the same structure and transformed data.Use Cases: Data enrichment, translation, summarization, content generation, classification, etc. — all within the query stream.

NL-Guided Query Generation

How it works: Similar setup with natural language queries (via a dedicated module).- Instead of a structured query object, users can pass a natural language prompt to .map() (e.g., “find active users from Spain”).- This prompt is sent to the API with instructions to convert it into a structured GenosDB query object (with query, order, field).- The generated query is then executed as the original .map() call.Use Cases: Makes queries accessible to non-technical users, enables natural language search, and simplifies flexible query UI design.

3. Conquering Space: Geospatial Operators

For applications that handle location data, GenosDB provides a geospatial operators module.New Available Operators:- $near: Filters nodes whose coordinates (e.g., node.value.location.latitude, node.value.location.longitude) are within a specific radius (in kilometers) of a given center point.- $bbox: Filters nodes whose coordinates fall within a geographical bounding box defined by min/max latitudes and longitudes.Seamless Integration: These operators can be used in the .map() query object like any standard operator, allowing geographic filters to be combined with others.Distance Calculation: Includes an internal function for Haversine distance calculation between two geographic points.

What Makes GenosDB Unique?

The combination of these features and its modular design make GenosDB stand out:- Merging Worlds: One of the few (if not the only) client-side solutions to natively and modularly integrate graph databases, P2P sync, advanced persistence, and now, AI and geo-extensions.- True Decentralization with Local Intelligence: Doesn’t rely on a central server for business logic or sync, yet can extend local capabilities via controlled interaction with external APIs (like AI).- Extensibility at its Core: The ease of adding new operators and processing modules (as demonstrated with AI and Geo) means GenosDB can evolve with any application’s needs.- Enhanced Developer Experience: Using natural language for queries (via AIQuery.js) or enriching data on the fly (via AIModule.js) simplifies complex tasks and enables new data interaction patterns.- Client-Side Efficiency and Autonomy: Running mostly on the client with optimized storage and async processing, it reduces server load and delivers faster, more resilient UX.

The Future is Distributed, Intelligent, and Modular

GenosDB isn’t just a database — it’s a platform for building the next generation of decentralized and intelligent web applications. Its modular architecture invites the community to contribute new operators, processing systems, and extensions, shaping a future where client-side database capabilities are limited only by our imagination.If you’re seeking an innovative way to handle graph data, sync it in real time, and extend its power in previously unthinkable ways — GenosDB deserves your attention.

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

📚 Wiki | additional notes and guides

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

Technical Features of GenosDB (GDB)

Esteban Fuster Pozzi — Tue, 17 Feb 2026 00:42:31 +0000

remove(id): Deletes a node and all of its associated edges.- clear(): Wipes all data from the local database.- use(middleware): Registers a middleware function to validate or transform incoming P2P operations before they are applied, enabling custom security and business logic. ## Querying & Data Access The map(...args) method is the heart of data retrieval in GenosDB, offering both static and real-time querying capabilities.- Powerful Filtering: Supports MongoDB-style queries, sorting, and pagination ($limit, $after).- Real-Time Reactivity: By providing a callback function, map enters a reactive mode. The callback receives event objects for all matching nodes, keeping your UI perfectly in sync with the database state.- Event Object: The callback receives ({ id, value, action, edges, timestamp }).- Event Actions: 'initial' (for the starting dataset), 'added', 'updated', and 'removed'.- Recursive Graph Traversal ($edge): A standout feature is the $edge operator. It allows you to perform complex, multi-hop traversals in a single query. You define a query to find the starting nodes, and the $edge sub-query filters all their descendants, returning a flat list of matching nodes from anywhere in the hierarchy. ## Concurrency & Consistency GenosDB is designed for distributed environments where conflicts are inevitable.- Hybrid Logical Clocks (HLC): Every operation is timestamped with an HLC, which combines physical time with a logical counter. This ensures a causal ordering of events across all peers.- Last-Write-Wins (LWW): Conflicts are automatically resolved using an LWW strategy based on the newest HLC timestamp. The system includes safeguards to prevent abuse from clients with manipulated system clocks.- Clock Sync: The local HLC is intelligently updated upon receiving remote operations, ensuring the causal chain is maintained across the network. ## P2P Synchronization & Networking (GenosRTC) When initialized with rtc: true, GenosDB enables its powerful GenosRTC module via the db.room object for direct, real-time peer-to-peer communication.- Peer Lifecycle Events: Automatically detect when peers connect or disconnect.- db.room.on('peer:join', (peerId) => ...)- db.room.on('peer:leave', (peerId) => ...)- Data Channels: Send any serializable data (JSON, strings, binary) through named channels. This is perfect for chat messages, cursor positions, or game state updates.- const channel = db.room.channel('channel-name')- channel.send(data)- channel.on('message', (data, peerId) => ...)- Media Streams: Stream audio and video directly to other peers for applications like video conferencing or voice chat.- db.room.addStream(localStream)- db.room.on('stream:add', (stream, peerId) => ...)- Cross-Tab Sync: Uses a BroadcastChannel to ensure consistency between multiple tabs of the same application within a single browser. It automatically handles recovery from tab inactivity. ## Storage & Persistence GenosDB prioritizes performance and reliability for its local storage engine.- Primary Storage: It leverages the Origin Private File System (OPFS) for high-performance, file-based storage when available. It uses synchronous file handles (createSyncAccessHandle) for maximum efficiency, falling back to asynchronous APIs or IndexedDB where necessary.- Dedicated Web Worker: All storage I/O is offloaded to a dedicated Web Worker. This prevents the main thread from being blocked and ensures a smooth user experience, even under heavy write loads. File-level locking and a write queue prevent race conditions. ## Performance & Efficiency
MessagePack: Data is serialized into the compact MessagePack binary format.- Pako (Deflate): Serialized data is compressed using Pako, significantly reducing storage footprint and network transfer sizes. ## Security & Configuration
End-to-End Encryption: By providing a password during initialization, all persisted data and P2P data channel communications are end-to-end encrypted.- Custom Validation: Use the db.use(middleware) method to implement custom authorization logic (e.g., RBAC) by validating all incoming remote operations against your own rules. ## Feature Summary GenosDB is a comprehensive solution for building decentralized, real-time web applications. Its combination of a local-first architecture, a powerful graph query engine, and seamless WebRTC-based P2P synchronization makes it an ideal choice for collaborative tools, multiplayer games, and any application that demands reactive data and offline capabilities without server dependencies. ---

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

📚 Wiki | additional notes and guides

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

Most Popular Peer-to-Peer Distributed Databases

Esteban Fuster Pozzi — Tue, 17 Feb 2026 00:41:17 +0000

By the end of this guide, you’ll understand not only what makes a true browser-native P2P database possible, but why it matters.

For developers building the next generation of web applications, the promise of a truly peer-to-peer (P2P) architecture is the ultimate goal: real-time collaboration, offline-first functionality, and resilience without costly, centralized servers.

But the journey to find the right “P2P database” is a treacherous one. The landscape is a confusing maze of protocols, libraries, and databases, many of which carry a legacy from a server-first world.

This guide is a developer’s map through that maze. We will start with the broad universe of distributed data technologies, apply a strict filter to find what is truly viable for modern, browser-native applications, and ultimately discover the solution that meets today’s demands for performance and security.

Step 1: The Great Filter — Separating Protocols from Products

The first challenge is that many technologies listed as “P2P databases” are actually low-level protocols or libraries, not integrated database solutions. They provide the building blocks but leave the hardest parts — storage, querying, and conflict resolution — to the developer.

Let’s apply our first filter: Is it a complete database, or a state synchronization library?

Libraries like Yjs, Automerge, and Trystero: These are brilliant CRDT and P2P communication libraries. They are exceptional at synchronizing the state of a JSON object or a text document in real-time. However, they are not databases. They don’t provide a persistent storage engine or a query API out of the box.
You still need to build your database on top of them, often by pairing them with IndexedDB.

Our quest is for a complete, out-of-the-box database. So, while these libraries are a crucial part of the ecosystem, we’ll set them aside for now.

Step 2: The Browser-Native Filter — Node.js vs. The Web

The next, and most critical, filter is: Can it run entirely within the browser, without a required Node.js runtime or backend daemon?

This is where the majority of powerful distributed technologies are eliminated for our specific use case.

Technologies like Hypercore Protocol (with Hyperbee), BigchainDB, and KappaDB: These are powerful, server-first P2P technologies. They are designed to run in environments with full filesystem and network access, like a Node.js server. While it’s sometimes possible to bridge them to a browser via WebSockets or WebRTC relays, this introduces a centralized component and complexity that violates our “truly P2P, browser-native” requirement.
They are not designed to be initialized and run directly and solely from a user’s browser tab.

After applying these two strict filters, the vast landscape shrinks dramatically. We are left with a handful of contenders that have genuinely attempted to solve the browser-P2P database challenge. This is where the real comparison begins.

Step 3: The Old Guard — A Look at the Pioneers

Two names have dominated this space for years: GunDB and OrbitDB. They were groundbreaking and laid the foundation for what was possible. Let’s analyze them with a modern developer’s perspective.

GunDB: The Resilient Veteran

GunDB is a legend. It was one of the first to offer a truly serverless, P2P graph database that runs in the browser.

Strengths:
- Truly Decentralized: It achieves P2P communication without mandatory servers, a remarkable feat.
- Resilient: Its CRDT-inspired approach to conflict resolution makes it robust.
Modern-Day Challenges:
- Mature Architecture: Built with earlier JavaScript conventions, the codebase may require some adaptation for developers accustomed to modern tooling and workflows.
- Performance Considerations: In high-throughput scenarios, its resource usage may require careful tuning, especially for performance-sensitive applications such as VR or real-time gaming.

Verdict: A pioneering technology that proved the concept, but its architecture shows its age. For new projects demanding peak performance, it presents significant hurdles.

OrbitDB: The IPFS-Powered Log

OrbitDB takes a different approach, building on the ambitious IPFS (InterPlanetary File System).

Strengths:
- Immutable Data: Its event-log structure is excellent for applications requiring a full history of changes.
- IPFS Integration: A natural fit if your application is already invested in the IPFS ecosystem.
Modern-Day Challenges:
- Heavy Dependency: js-ipfs, the browser implementation of IPFS, is notoriously resource-intensive, increasing bundle size and memory usage.
- Browser Limitations: The browser version of IPFS often relies on gateway servers or has persistence issues, compromising the “truly P2P” ideal.

Verdict: An interesting choice for IPFS-native apps, but its heavy dependencies and browser performance issues make it a difficult recommendation for general-purpose web apps.

“These systems proved what was possible — but the web itself has evolved. Today’s browsers, APIs, and performance expectations call for a new foundation.”

Step 4: The Paradigm Shift — Introducing GenosDB

After exploring the strengths and limits of earlier solutions, it becomes clear that a new generation of P2P databases needs to approach the browser differently — one that blends performance, simplicity, and resilience by design.

GenosDB is a distributed, real-time graph database built for the modern web from the ground up. It doesn’t compete with the pioneers — it builds on their lessons.

How GenosDB Evolves the Model

Performance by Design: GenosDB employs debouncing as a first line of defense against transmission overload. Instead of relying on cascading ACK chains like in GUN’s mesh, it manages load proactively — coalescing writes, batching network operations, and balancing disk I/O. This prevents backpressure before it occurs, keeping both peers and the UI responsive under heavy load.

Modern Persistence: By using the Origin Private File System (OPFS) for high-throughput, non-blocking storage, GenosDB achieves the performance of native databases directly in the browser, with zero external dependencies.

Efficient Communication: The WebRTC-based sync layer was rewritten for predictable behavior and low overhead, avoiding redundant message floods through a debounced task pipeline.

Compact & Secure: Data is serialized with MessagePack and compressed with Pako, ensuring minimal footprint over the wire. A built-in Security Manager (SM) brings RBAC and WebAuthn support for a zero-trust environment — something older P2P databases never had to tackle directly.

Developer Experience: Its modular, asynchronous design makes it approachable yet powerful. The graph API supports advanced recursive traversals and reactive queries out of the box.

“Here’s a quick summary of how the leading P2P databases compare in focus and strengths.”

GunDB

Vibe: The Resilient Pioneer.
Best For: Simple, decentralized apps where resilience is key and performance is not critical.
Watch Out For: Legacy architecture, potential performance issues, and unpredictable states in complex apps.

OrbitDB (with js-IPFS)

Vibe: The IPFS-Native Log.
Best For: Applications deeply integrated with the IPFS ecosystem that need an immutable history.
Watch Out For: Heavy performance overhead, large bundle size, and browser-related complexities of IPFS.

GenosDB

Vibe: The High-Performance Modern Successor.
Best For: New, demanding web applications requiring real-time collaboration, high performance, modern security, and a superior developer experience.
Key Features: OPFS storage, built-in RBAC + WebAuthn, lightweight P2P layer, advanced graph database built with a Zero-Trust Security Model

Choosing the Right P2P Database

GunDB remains one of the most important milestones in the journey toward a decentralized web. Its community, perseverance, and years of experimentation proved that a peer-to-peer database could truly run in the browser — long before most believed it was possible.

GenosDB was built from the ground up to redefine data synchronization on the web through its innovative GenosRTC protocol.

It takes a different approach — a modular, top-level-await factory design — where every layer, from the storage engine to the real-time network flow, is engineered to remove the bottlenecks and assumptions that have constrained peer-to-peer systems for years.

Driven by an obsession with speed, stability, and simplicity, GenosDB delivers a truly modern architecture — built for today’s web and ready for what comes next.

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

📚 Wiki | additional notes and guides

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

GenosDB Represents Hierarchical and Inheritance Relationships

Esteban Fuster Pozzi — Tue, 17 Feb 2026 00:41:11 +0000

GenosDB is a name with meaning intrinsically linked to the nature of graphs, providing clear identity, conceptual relevance, and competitive advantage in describing the fundamentals of a distributed database.The term genos originates from the Greek word γένος, meaning: origin, lineage, class, type, or family. This makes it conceptually appropriate for a graph-based database, as it reflects hierarchical structures and relationships between nodes.Key reasons that led me to name my distributed database project “GenosDB”:- Represents hierarchical and inheritance relationships:- In graphs, connections often reflect structures such as lineages, types, or categories. Genos evokes these ideas, which are natural for modeling interrelated data.- Evokes structure and organization:- It reflects how nodes can be grouped into “families” or classes, which is useful for semantic or knowledge graphs.- Unique and memorable:- It is not saturated in search engines or the tech ecosystem, which facilitates identity and positioning.- Compatible with the GDB acronym:- It maintains coherence with the project’s initials without causing confusion with existing databases.

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

📚 Wiki | additional notes and guides

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn